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

[markus1234]

Wie gesagt nur eine Vermutung.

 

[careyer]

So, zum Start des Wochenendes habe ich nochmal einige Sachen getestet, die ich gerne mit euch teile:

1.) Bei Nutzung von MissionPlanner (Windows) steht definitv nicht die Windows Firewall im Weg. UDP Port 14550 habe ich sowohl eingehend (vorsichtshalber auch ausgehend) explizit freigeschaltet. Es kommt weiterhin keine Verbindung zustande. (Die PC Version von QGC läuft dagegen out of the box)

2.) Den Grund für die verhältnismäßig hohe Anzahl verlorener Pakete und damit einhergehend auch Bad Blocks (Post 1081) habe ich auch gefunden: Ich nutze als TX eine Alfa 052NH Karte. Natürlich hatte ich den USB-Power-Mod gemacht und die 5V Versorgungsspannung vom BEC direct an die USB Buchse vom Raspi gelegt und dort dann die WLAN Karte angeschlossen ... ABER... der Querschnitt der Leitungen (dünnes Servokabel) war augenscheinlich zu gering und die leistungshungrige 052NH hat derart große Spannungsabfälle beim Senden generiert, dass die Karte es offenbar nicht mehr geschafft hat alle Pakete sauber auf's Medium aufzumodellieren. Ich habe jetzt sämtliche Kabel vom BEC bis hinein in die WLAN-Karte durch 0,5mm² Kabel ersetzt und siehe da: von 500.000 Paketen nur 22 Pakete verloren und 2 Bad Blocks. Also eine GAAANZ andere Hausnummer

3.) Jemand hatte berichtet, dass es beim via RTP weitergeleiteten Video in QGC zu vielen Artefakten kommt wohingegen der HDMI Output sauber ist. Auch dieses Problem ist durch 2. vollkommen verschwunden - wieso erschließt sich mir zwar nicht, aber den Effekt hatte ich auch ganz extrem und jetzt mit dem größeren Querschnitt ist das Problem vollkommen weg

4.) Ich habe dann auch versucht das USB-Tethering zu aktivieren - nach der Anleitung im Wiki. Hat leider nicht geklappt. nach ca. 2h rumprobieren habe ich dann rausgefunden, dass man am RX den Ethernet_Hotspot aktivieren muss. Erst dann klappts. Rodizio, vielleicht kannst du das ins Wiki mit aufnehmen?

 

[r0ck3t]

3.) Jemand hatte berichtet, dass es beim via RTP weitergeleiteten Video in QGC zu vielen Artefakten kommt wohingegen der HDMI Output sauber ist. Auch dieses Problem ist durch 2. vollkommen verschwunden - wieso erschließt sich mir zwar nicht, aber den Effekt hatte ich auch ganz extrem und jetzt mit dem größeren Querschnitt ist das Problem vollkommen weg

Ich hab das Problem mit Artefakten bei USB-Tethering am Android Tablet, so wie es aussieht wie alle anderen auch, denke also es sollte nicht mehr an der Spannungsversorgung liegen.
Oder klappt genau das jetzt bei dir?

4.) Ich habe dann auch versucht das USB-Tethering zu aktivieren - nach der Anleitung im Wiki. Hat leider nicht geklappt. nach ca. 2h rumprobieren habe ich dann rausgefunden, dass man am RX den Ethernet_Hotspot aktivieren muss. Erst dann klappts. Rodizio, vielleicht kannst du das ins Wiki mit aufnehmen?

Bei mir ging das einwandfrei, alllerdings erst nachdem ich Ethernet_Hotspot deaktiviert habe und am Tablet das USB Tethering aktiviert habe sodass das Tablet als Gateway funktioniert. Hattest du tethering in Android aktiviert?

 

[rodizio1]

jpfeifer:
Wie rocket schon richtig vermutet hat ist RC_RSSI für die wifibroadcast R/C Funktion über Joystick, das OSD starte nicht, weil Du die Funktion nicht nutzt. Werde das im nächsten Release WBC_RC_RSSI oder so nenen, damit es klarer ist.


rocket:

@rodizio: Wie kann ich am Einfachsten am TX über wbc gesendete telemtrie loggen? Würd gern sehen was da ankommt...

Schau' mal in der osdtx_function, die Zeile "nice cat $FC_TELEMETRY_SERIALPORT ..." da ein tee zwischenhängen was die Telemetrie irgendwo auf die sdkarte schreibt. Vorher noch "rw" im Script machen ...


careyer:

Habe gerade rausgefunden, dass MissionPlanner ebenfalls RTP.H264 empfangen kann wenn gstreamer auf dem PC installiert ist. Soll wohl out-of-the-box funktionieren. Allerdings nur wenn auf Port 5600 gesendet wird.
Soweit ich weiß sendet EZ-WBC auf Port 5000, oder? In QGC musste ich auch den Port von 5600 erstmal auf 5000 ändern damit es lief. Ist es Absicht, dass WBC nicht auf dem "Standard"-Port sendet und wenn ja, wo könnte ich das in WBC ändern? Gibt es dafür irgendwo eine Config (wenn ja wo)?

Irgendwie hat sich 5000 "eingebürgert", weiss nicht mehr woher das kam, habe die Nummer auch nur übernommen. Wenn ich das Default auf 5600 ändere, müsste man den Port aber erst in der VR_APP ändern, bringt also auch nichts. Ändern kannst Du den in der /root/.profile, da gibt's eine Zeile "VIDEO_UDP_PORT=5000"

Zu 1.)
Also wieder abhängig vom genutzten Programm? QGC geht, Mission Planner nicht? (Auf dem gleichen PC?)

Zu 2.)
Ja, sag' ich immer wieder und steht auch alles im Wiki, aber will ja keinr hören Packetloss sollte auch bei Null bleiben, auch durch mehrere Wände hindurch. Draussen am Copter (?) sollte mit der Antennen-Combo mindestens 1.5km gehen wenn die Antennen schön frei montiert sind, sodass mindestens eine immer Sichtkontakt zum Empfänger hat.

Zu 3.)
Das klingt wirklich Komisch. Habe jetzt auch mal mit QGC das Video getestet, bekomme auch diese seltsamen Artefakte, aber seltsamerweise nur bei schnellen Kamerabewegungen. Wenn die Cam unbewegt ist oder nur langsam umherschwenke ist alles gut. Seltsam.

Zu 4.)
Das USB-Tethering funktioniert genauso wie im Wiki angegeben, es muss *nichts* konfiguriert werden. Die Ethernet- oder Wifi-Hotspot Optionen in der Konfig haben damit überhaupt nichts zu tun, die funktionieren auf ganz anderen Interfaces. Habe gerade nochmal mit meinem S5 getestet, geht immer, völlig egal ob Ethernet- oder wifi-Hotspot ein- oder ausgeschaltet. Bist du *ganz* sicher, dass das nicht an irgendwas anderem lag?

 

[careyer]

Irgendwie hat sich 5000 "eingebürgert", weiss nicht mehr woher das kam, habe die Nummer auch nur übernommen. Wenn ich das Default auf 5600 ändere, müsste man den Port aber erst in der VR_APP ändern, bringt also auch nichts. Ändern kannst Du den in der /root/.profile, da gibt's eine Zeile "VIDEO_UDP_PORT=5000"

Okay, danke - das hilft schon mal weiter! =) Mir war nur aufgefallen, dass Port 5600 im MissionPlanner fix vorgegeben ist und nicht geändert werden kann und auch in QGC der Port standardmässig auf 5600 steht. VR_APP hatte ich bis dato noch nicht genutzt da nur Videodarstellung und keine vollständige GCS Lösung.

Zu 1.)
Also wieder abhängig vom genutzten Programm? QGC geht, Mission Planner nicht? (Auf dem gleichen PC?)

Genau so. Gleicher PC: QGC geht problemlos. Mit MissionPlanner kommt aufs verrecken keine Verbindung zustande. Den Port 14550 habe ich explizit in der Firewall für alle Programme freigegeben. (Funktionierte aber auch ohne Freischaltung it QCG vorher schon). Irgendwo ist da mit MissionPlanner der Fuck drin.

Zu 2.)
Ja, sag' ich immer wieder und steht auch alles im Wiki, aber will ja keinr hören Packetloss sollte auch bei Null bleiben, auch durch mehrere Wände hindurch. Draussen am Copter (?) sollte mit der Antennen-Combo mindestens 1.5km gehen wenn die Antennen schön frei montiert sind, sodass mindestens eine immer Sichtkontakt zum Empfänger hat.

Jepp, deshalb hatte ich den USB-Power Mod auch von Anfang an gemacht - nur augenscheinlich mit zu dünnen Kabeln. Jetzt mit größerem Querschnitt ist das aber ein Unterschied wie Tag und Nacht. Wobei man natürlich auch berücksichtigen muss, dass der 052NH mit den beiden Sendeendstufen überdurchschnittlich viel Leistung zieht.

Zu 3.)
Das klingt wirklich Komisch. Habe jetzt auch mal mit QGC das Video getestet, bekomme auch diese seltsamen Artefakte, aber seltsamerweise nur bei schnellen Kamerabewegungen. Wenn die Cam unbewegt ist oder nur langsam umherschwenke ist alles gut. Seltsam.

Dito. Dieselben Effekte hatte ich auch - Schnelle Bewegungen oder Schwenks führten zu Artefakten. Ist jetzt nach der Maßnahme von 2.) weg. Unerklärlich wieso...ist aber so ;-)

Zu 4.)
Das USB-Tethering funktioniert genauso wie im Wiki angegeben, es muss *nichts* konfiguriert werden. Die Ethernet- oder Wifi-Hotspot Optionen in der Konfig haben damit überhaupt nichts zu tun, die funktionieren auf ganz anderen Interfaces. Habe gerade nochmal mit meinem S5 getestet, geht immer, völlig egal ob Ethernet- oder wifi-Hotspot ein- oder ausgeschaltet. Bist du *ganz* sicher, dass das nicht an irgendwas anderem lag?

Jepp.. ganz sicher - grad nochmal verifiziert! Ich hab hier ein Nexus 7 mit Android 6.0.1. Wenn man USB-Tethering aktiviert zwingt er die USB Konfiguratation auf "RNDIS (USB Ethernet)" d.h. er simuliert mit dem Tablet ein Ethernet via USB Device. Ergibt also auch Sinn den Ethernet-HOTSPOT am RX zu aktivieren. Ohne geht es schlichtweg nicht. Das Tablet zeigt zwar eine USB-Tethering Verbindung an aber es kommt weder eine Daten- noch eine Videoverbindung zustande.
Ist ggf. von Android zu Android Version vielleicht etwas unterschiedlich. Schaden tut es aber zumindest nicht den Ethernet-HOTSPOT zu aktivieren. Hilft vielleicht dem ein oder anderem bei der Fehlersuche ;-)

 

[rodizio1]

Jepp.. ganz sicher - grad nochmal verifiziert! Ich hab hier ein Nexus 7 mit Android 6.0.1. Wenn man USB-Tethering aktiviert zwingt er die USB Konfiguratation auf "RNDIS (USB Ethernet)" d.h. er simuliert mit dem Tablet ein Ethernet via USB Device. Ergibt also auch Sinn den Ethernet-HOTSPOT am RX zu aktivieren. Ohne geht es schlichtweg nicht. Das Tablet zeigt zwar eine USB-Tethering Verbindung an aber es kommt weder eine Daten- noch eine Videoverbindung zustande.
Ist ggf. von Android zu Android Version vielleicht etwas unterschiedlich. Schaden tut es aber zumindest nicht den Ethernet-HOTSPOT zu aktivieren. Hilft vielleicht dem ein oder anderem bei der Fehlersuche ;-)

Nein, das ergibt immer noch überhaupt gar keinen Sinn. Was macht Dein Tablet genau? Es simuliert eine Netzwerkkarte und ist dabei Client und ziegt sich per DHCP eine IP Adresse? (Also NICHT wie beim USB-Tethering was ich kenne Server?)
Die Ethernet Hotspot Konfig bzw. der udhcp läuft eigentlich nur auf dem Ethernet-Interface, würde mich wundern wenn der eine IP-Adresse auf dem USB Interface verteilt ...

Welche Meldung genau kommt bei Dir am HDMI Bildschirm wenn Du das Tablet per USB-Tethering verbindest?

"Secondary display connected (Hotspot)"
oder
"Secondary display connected (USB)"

 

[careyer]

Ich bekomme die Meldung "Secondary display connected (USB)" ... auf die Meldung hatte ich bisher ehrlich gesagt gar nicht geachtet Wie dem auch sei... LÄUFT! TOP!!=)

Wetter ist nur leider vollkommen be***** - wollte eigentlich dies WE mal raus testen! GRR!!!

 

[rodizio1]

Wie gesagt, gibt überhaupt keinen Sinn. Sind zwei völlig unterschiedliche Funktionen im Script. Wenn die Meldung mit "USB" in Klammern kommt, muss es also der USB Tethering Teil des Scriptes sein der das Tablet erkannt hat und nicht die Ethernet Hotspot Funktion. Schwer zu sagen was das los ist, funktioniert wahrscheinlich nur durch irgend einen seltsamen Zufall und ist nicht so gedacht.

 

[careyer]

Hauptsache läuft nur beim Mission Planner gehen mir die Ideen langsam aus. Hast du die Möglichkeit das mal zu probieren?


Gesendet von iPhone mit Tapatalk

 

[rodizio1]

Hauptsache läuft

Für Dich als Anwender mag das erstmal okay sein. Ist aber im Grunde nur Zufall oder ein Bug, dass das so läuft. Das gefällt mir als Entwickler gar nicht

Ich habe das Gefühl, wenn ich Missionplanner probiere, wird es entweder gehen oder nicht gehen, aber der Grund dafür wird sich mir wie bei den anderen GCS wieder nicht erschliessen.

Werde zur Sicherheit demnächst nochmal diverse Kombinationen aus GCS Software und Cleanflight/Inav Versionen durchprobieren und dabei jeweils Captures von den Daten auf der seriellen Schnittstelle und auch den UDP Paketen die cmavnode generiert machen. Wenn sichergestellt ist, dass alles wirklich 1:1 korrekt durchgeleitet wird, Issues auf den Github Seiten der GCS eröffnen.

 

[r0ck3t]

rocket:
Schau' mal in der osdtx_function, die Zeile "nice cat $FC_TELEMETRY_SERIALPORT ..." da ein tee zwischenhängen was die Telemetrie irgendwo auf die sdkarte schreibt. Vorher noch "rw" im Script machen ...

Es ging mir eher um die andere Richtung, der Downlink funktioniert ja einwandfrei. Habe also in der entsprechenden Funktion (Telemetrie Empfang am TX) die empfangenen Daten direkt auf SD Karte geschrieben und angesehen. Die Daten die von der GC Software (QGC/Tower) versendet wurden kommen am TX alle sauber an. Dort werden sie ja über die serielle an den Pixhawk übertragen, denke nachdem ich alles andere ausgeschlossen habe ist dort der Fehler zu suchen. cmavnode leitet die an 60000 empfangenen Pakete ja dann wieder an die Serielle, ist die richtig konfiguriert?

Mein Stand sieht jetzt so aus:
macOS, QGC: Telemetrie Downlink OK, Video OK
macOS, APM: Telemetrie Downlink OK
Android, QGC: Telemetrie Downlink OK, Video Artefakte
Android, Tower: Telemetrie Downlink OK, Video führt zum Absturz der App

Edit: Ich denke ich hab den Fehler, ich hab Deine stty options für die virtuellen comports direkt übernommen, natürlich muss da die Baudrate stimmen, also auf 57600 (wie auch bei mir am FC) eingestellt und siehe da, der FC versteht auf einmal die mavlink messages wieder.
Auf den ersten Blick sieht es jetzt so aus als ob alles sauber läuft, einzig QGC (Android) hat Problemchen beim Abrufen der Mission und Tower (Android) beim Abrufen der Parameter. Ich kann das nochmal per 3DR Radio testen, dann weis ich ob die Software schuld ist, gehe aber davon aus.

 

[rodizio1]

Du hast jetzt nichts geändert, ausser die baudrate des virtuellen com ports auf 57.600 gestellt und es geht (Die sollte eigentlich egal sein, hatte nur zur sicherheit 115200 genommen damit sie auf jedenfall gleich oder höher ist)?



Ansonsten gibt's ein paar gute Neuigkeiten zur 1.6er Entwicklung:
- Bandbreitenmessung scheint soweit zu funktionieren, man braucht nur noch die Wifi Datenrate vorgeben und FEC Parameter einstellen, Videodatenrate wird automatisch eingestellt. D.h. insgesamt mehr Videobitrate weil ich weniger "Sicherheit" lassen muss. Und Ihr könnt endlich schnell und problemlos verschiedene FEC Settings testen.
- tx mit RAW sockets (ohne libpcap) läuft, weniger syscalls und context switches, tx Prozess macht ca. 5-10% weniger CPU Last, d.h. auf dem Pi0 ist jetzt wieder etwas 'Luft'
- Kernel 4.9 scheint das jitter Problem auf dem USB Bus gefixt zu haben, -d 1 scheint wieder zu gehen. Gibt ca. 10-15ms weniger Latenz

 

[r0ck3t]

Du hast jetzt nichts geändert, ausser die baudrate des virtuellen com ports auf 57.600 gestellt und es geht (Die sollte eigentlich egal sein, hatte nur zur sicherheit 115200 genommen damit sie auf jedenfall gleich oder höher ist)?

Ich habe erst alle empfangenen Messages am TX mitgeschrieben, da hat der FC gar nicht reagiert. Danach habe ich nur die Baudrate des virtuellen Comports geändert dann funktionierte der Uplink.
Ich kann das nochmal nachtesten um ganz sicher zu sein.

 

[rodizio1]

Ja, wäre cool. Werde mir die socat optionen auch nochmal anschauen bzw. mal im Netz suchen ...

Oder stell' alles auf 115.200 incl. FC, die Bandbreite 'over the air' ist ja im Gegensatz zu den 3DR Dongles nicht mehr der limitierende Faktor, theoretisch sollte Parameter-Abrufen und Missionen hochladen dann ziemlich schnell gehen.

 

[careyer]

Heute in der Post gewesen ;-). Passen auf die CSL Sticks wie Ar*** auf Eimer!

Gesendet von iPhone mit Tapatalk

 

[r0ck3t]

Ja, wäre cool. Werde mir die socat optionen auch nochmal anschauen bzw. mal im Netz suchen ...

Oder stell' alles auf 115.200 incl. FC, die Bandbreite 'over the air' ist ja im Gegensatz zu den 3DR Dongles nicht mehr der limitierende Faktor, theoretisch sollte Parameter-Abrufen und Missionen hochladen dann ziemlich schnell gehen.

Also ich hab kurzfristig nur die zwei virtuellen comports auf 115 zurück gestellt und es ging nicht mehr, allerdings danach wieder auf 57 und es ging immer noch nicht. Danach alles auf 115 (natürlich inklusive FC) und wieder keine Veränderung.

Jetzt bin ich drauf gekommen das der Uplink einfach sehr unzuverlässig ist, also die Daten werden noch korrekt übertragen (zumindest schaut das log am TX gut aus inklusive der CRCs), aber irgendwo zwischen Empfang und Serieller zum FC passiert dann etwas und nur etwa 10% der Nachrichten kommen zum FC durch.

Warum ich dachte es geht nach umstellen der virtuellen comports? Das war einfach Zufall, aus irgendeinem Grund gingen einfach mehr Pakete durch und es sah deswegen OK aus.

Also entweder socat bzw. cmavnode macht irgendwie (random) Pakete kaputt, oder irgendetwas anderes bei der Umsetzung wbc auf seriell geht schief.

 

[stxShadow]

Ansonsten gibt's ein paar gute Neuigkeiten zur 1.6er Entwicklung:
- Bandbreitenmessung scheint soweit zu funktionieren, man braucht nur noch die Wifi Datenrate vorgeben und FEC Parameter einstellen, Videodatenrate wird automatisch eingestellt. D.h. insgesamt mehr Videobitrate weil ich weniger "Sicherheit" lassen muss. Und Ihr könnt endlich schnell und problemlos verschiedene FEC Settings testen.
- tx mit RAW sockets (ohne libpcap) läuft, weniger syscalls und context switches, tx Prozess macht ca. 5-10% weniger CPU Last, d.h. auf dem Pi0 ist jetzt wieder etwas 'Luft'
- Kernel 4.9 scheint das jitter Problem auf dem USB Bus gefixt zu haben, -d 1 scheint wieder zu gehen. Gibt ca. 10-15ms weniger Latenz

Hmmm .... der "beta" Kernel, den wir testen sollten war aber doch ein 4.4.11 ..... sind diese Tests also nutzlos oder gibt es irgendwo den 4.9er zum testen ?

Jens

 

[rodizio1]

rocket: Auf Rcgroups hatte jemand Probleme mit seinem Antennentracker, dieser hat Mavlink Pakete nicht erkannt weil die Mavlink Pakete nicht 'am stück' und zu 'bursty' aus dem wbcrx bzw. dem seriellen Port kommen. Er hat das irgendwie in seinem Code gefixt und zusätzlich noch einen schnelleren Prozessor für den Tracker genommen, dann ging es. Kann es sein, dass die FC das gleiche Problem hat? Ausser einen extra telemetry tx/rx zu schreiben der sicherstellt das immer eine mavlink message in ein wbc paket kommt fällt mir jetzt erstmal nichts mehr ein (Davon ausgehend, dass zwischen dem wbcrx auf dem Air-Pi und der seriellen Schnittstelle keine Daten kaputtgehen)

StxShadow: Das neue Raspbian release mit dem 4.9er kernel kam dummerweise kurz nachdem ich den alten kernel online gestellt habe. Im Moment kann ich nicht sagen was es werden wird. Der 4.9er ist definitv besser und läuft soweit, aber ich habe noch nicht viel getestet ausser einmal über Nacht laufen lassen. Ich hoffe der stellt sich als stabil heraus, dann wird's mit dem weitergehen. Falls nein, bleibt's erstmal bei dem 4.4er.


Edit: Mir fällt doch noch was ein Cmavnode hat glaube einen verbose mode, schau' vielleicht mal ob das irgendwas loggt (/wbc_tmp/cmavnode.log)

 

[r0ck3t]

rocket: Auf Rcgroups hatte jemand Probleme mit seinem Antennentracker, dieser hat Mavlink Pakete nicht erkannt weil die Mavlink Pakete nicht 'am stück' und zu 'bursty' aus dem wbcrx bzw. dem seriellen Port kommen. Er hat das irgendwie in seinem Code gefixt und zusätzlich noch einen schnelleren Prozessor für den Tracker genommen, dann ging es. Kann es sein, dass die FC das gleiche Problem hat? Ausser einen extra telemetry tx/rx zu schreiben der sicherstellt das immer eine mavlink message in ein wbc paket kommt fällt mir jetzt erstmal nichts mehr ein (Davon ausgehend, dass zwischen dem wbcrx auf dem Air-Pi und der seriellen Schnittstelle keine Daten kaputtgehen)

Edit: Mir fällt doch noch was ein Cmavnode hat glaube einen verbose mode, schau' vielleicht mal ob das irgendwas loggt (/wbc_tmp/cmavnode.log)

Also das wäre eine Erklärung, könnte man eigentlich mit tcpdump am tx nachvollziehen. Bzgl. Cmavnode, weis nicht wie ich da debug enable, seh keine config option dafür.

 

[rodizio1]

in der .profile in der Zeile wo cmavnode (einfach nach "/root/cmavnode/cmavnode" suchen ...) gestartet wird, "--verbose" hinzufügen als option.