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

[rodizio]

Cooles Setup hast Du da gebaut

Hmmm, das ist seltsam, an der Stelle habe ich nichts geändert wenn ich mich nicht täusche. Vielleicht ein Stromversorgungsproblem? Du könntest mal versuchen in der config.txt das Übertakten wieder rauszunehmen (gpu_freq, cpu_freq, sdram_freq und over_voltage wieder auskommentieren).


Das "Operation Failed" kommt vom DHCP client wenn kein Netzwerkkabel angeschlossen ist und er keine IP bekommt deswegen. Muss mal schauen ob ich das noch wegbekomme, verwirrt nur.


Der TX gibt seit v1.2 auch ein paar Debug-Infos aus, hast Du da mal einen Monitor angeschlossen?

 

[brandtaucher]

@rodizio: Hab ich das im Paralleluniversum richtig verstanden, dass man mit Deinem Image auch USB-Cams verwenden kann? Stimmt das? Ist das Plug & Play oder muss man da noch irgendwo was ändern?

 

[rodizio]

Nee, ist nicht Plug&Play, es sind nur die Tools wie video4linux und gstreamer schon installiert.

Müsstest dazu am TX anstatt raspivid gstreamer als Quelle nehmen. Am RX müsste es ohne Änderungen laufen wenn die Webcam H264 ausgibt, bei MJPEG müsste man da auch den gstreamer oder irgendwas was MJPEG anzeigen kann nehmen.

 

[FPV-LE]

Da mein Setup mit den 5.8Ghz_RCGroup-IMG_LongF - Dateien nicht mehr funktionieren will (und nie richtig funktioniert hat) will ich diese Images hier testen. Danke für Deine Arbeit.

Und erste Frage: wie bekomme ich USB-Tethering mit Smartphone zum laufen? DIe Frage tauchte hier im Thread auf, aber ohne Lösung. Gibt es mittlerweile eine?

EDIT 2: WOW, das bootet wesentlich schneller als das obige Image. Gut gemacht ! Und funktioniert auf Anhieb.
Jetzt noch USB-Tethering . Ich vermute an die Stelle des Display Program müsste wieder socat, oder? Leider ist das System read only. Am coolsten wäre es, wenn die "Sendezeile" in der config.txt enthalten wäre und damit einfach über Windows editierbar.

EDIT3: habe jetzt "Display Program" durch socat -b 1024 - udp4-sendto:192.168.42.129:5000 ersetzt und das Ergebnis ist leider das gleiche wie mit dem alten Image: kein Bild .
Kann jemand helfen? Ideal wäre natürlich WLAN-Hotspot-Verbindung statt USB-Kabel

 

[rodizio]

Die Funktionalität ist noch nicht drin, werd' ich wahrscheinlich im nächsten Release machen (Muss noch mein Telefon auf Android 5 updaten vorher ...).

Read/Write mounted geht mit "rw". Hast Du eine IP Adresse geholt? Müsstest wohl noch irgendwo "pump -i usb0" hinzufügen. Bist Du sicher, dass die .129 die richtige IP vom Telefon ist? Als ich das mal kurz getestet hatte, war mein Telefon die .1 ...

 

[FPV-LE]

In der Android-App wird diese Ping angezeigt, und soweit ich weiß ist die Ping immer exakt diese wenn man USB-Tethering nutzt.

EDIT: es läuft jetzt, Ausgabe auf Handy funktioniert. Es musste nur in der interfaces-Datei der USB0 aufgenommen werden, und pump -i usb0 reicht aus, damit die Übertragung klappt.

Nur - warum ist Bildquali so viel schlechter und die Anzahl der übertragenen "Nalus" so viel geringer / langsamer, als mit dem alten Image 5.8Ghz_RCGroup-IMG_LongF? Um genau zu sein erkennt man rein gar nix auf dem übertragenen Bild ...

Außerdem - wie kann ich das Ganze weitgehend automatisieren? Den pump-Befehl in die rx.sh aufnehmen klappt schonmal nicht, liefert Operation failed.

EDIT4: klappt jetzt wunderbar. Die buffer-size bei socat hatte nen Tippfehler drin, mit 1024 klappt es. Bleibt nur die Automatisierung: also automatisch pump usb0, und eine Korrekturfunktion, falls das USB-Kabel wackelt und die Tether-Verbindung abreißt. Kann jemand einen Vorschlag machen? Kenne mich mit Linux nicht gut genug aus

 

[FPV-LE]

Vorweg – ich habe kaum Grundlagenwissen über Linux, und habe mir das folgende aus Foren und Artikeln zusammengestückelt. Es kann sicher noch optimiert werden.
Aus dem Gedächtnis …:


0 Tastatur, Monitor, WLAN-Stick an RX-RPi anschließen
1 Power on
2 bissl warten, bis Cursor blinkt; dann gestartetes Wifi-Broadcast-Script mit STRG+C abbrechen
3 ihr landet in der Commandozeile
4 Schreibzugriff einrichten: sudo mount –o remount, rw /
5 usb0 in interfaces aufnehmen; Weg:
sudo nano etc/network/interfaces
Zeilen ergänzen:
allow-hotplug usb0
iface usb0 inet dhcp

6 socat-Sendezeile in rx.sh aufnehmen; Weg: sudo nano home/wifibroadcast_fpv_scripts/rx.sh; nun in der if-else Schleife, wo gesendet wird:
$DISPLAY_PROGRAM löschen (hinter dem senkrechten Strich!)
an die Stelle wo das stand, muss hin: socat –b1024 – udp4-sendto:192.168.42.129:5000

7 Schreibzugriff entfernen: sudo mount –o remount, ro /
8 sicherheitshalber restart mit sudo reboot; danach Punkte 1-3 nochmal abarbeiten;
9 Handy an Rpi anschließen, USB-Tethering in den Netzwerkeinstellungen aktivieren
10 sudo pump –i usb0 ausführen
11 Copter hochfahren bzw. TX-Rpi, warten bis LED der Cam leuchtet
12 sudo bash home/wifibroadcast_fpv_scripts/rx.sh
13 Android-App starten (nach „MyMediaCodecFpv“ aufm Board suchen, falls unbekannt),
14 auf Test activity oder gleich auf Bildübertragung gehen => müsste laufen

alles aus dem Gedächtnis, Fehler sind möglich;


Fehlerquellen:

Punkte 9 und 10 vertauschen wenns nicht klappt

Symptom: Handy verbindet und trennt sich ständig; Grund: Spannungsversorgung unzureichend;* Lösung: besseren Akku oder UBEC besorgen;

ODER: USB-Kabel unzuverlässig (Stecker oder Buchse wackelig; „nur Strom“-Kabel benutzt – ein Datenkabel ist notwendig)


NOCH zu realisieren:
automatisch deutsche Tastatur, biiiiitte !!

BLUETOOTH via GPIO erlauben - ich dreh noch durch wenn ich weiter mit AMitastatur am Minimonitor scripte schreiben muss !!!

pump –i usb0 automatisch starten => wo im System muss das passieren? sbin/ifup? Ich teste das noch.

Eine Funktion, die folg. ermöglicht: wenn auf dem Feld die USB-Verbindung Probleme macht, soll sich der RPi automatisch wieder mit dem Handy verbinden, wenn das USB-Kabel wieder steckt. Ohne Reboot bzw. ohne Eingriff auf Commandozeile ! Ich hatte das mit dem alten Image mit while…true schon geschafft, bei diesem hier macht der pump-Befehl Probleme.

 

[FPV-LE]

Habe es jetzt geschafft dass die rx.sh wartet, bis die Tethering-Verbindung steht (until-ping-Schleife...).
Leider muss ich die rx.sh immernoch manuell starten. Wenn ich es einfach starten lasse (also nur einschalte) dann bekomme ich lediglich ein "Operation failed" angezeigt. Was dort genau failed, weiß ich nicht.

Daher meine Frage: was macht das System nach dem starten? Welches Script läuft? Woher kommt das failed? Ich dachte immer es wäre die rx.sh. Kann aber nicht sein: wenn ich die das gefailde abbreche mit STRG+C und dann rx.sh manuell anstoße faild nichts (sondern das Script wartet auf Tethering - wie ich es wollte).

 

[rodizio]

Das failed komm vom "pump eth0" wenn kein Netzwerkkabel angeschlossen ist. Findest Du wie auch die obere und untere Statuszeile in /home/pi/.profile.

die rx.sh wird wie in Befis image über den wbcrxd systemd service gestartet. Weiss nicht wieso Du die manuell starten musst bzw. solltest, die wird automatisch gestartet.

Edit: Wenn Du die .profile mit Strg-C abbrichst, wird auch das rx script nicht beendet. Wenn du dann manuell rx startest laufen theoretisch zwei. Irgendwas ist da noch komisch.

 

[FPV-LE]

Das operation failed blockiert das weitere fortkommen. rx.sh wird offenbar gar nicht erst gestartet (habe testhalber ein readkey eingebaut, am Beginn der rx.sh).

Ich musste die rx.sh anfangs auch nicht manuell starten, erst seitdem ich die rx.sh geändert habe um Tethering zu ermöglichen. An anderen Stellen habe ich aber nicht geschraubt.

Übrigens: hast Du irgendwas weggelassen, was für Bluetooth notwendig ist (HC-06 am GPIO ... serial ...)?

 

[rodizio]

Das operation failed blockiert das weitere fortkommen.

Nein, das sieht nur so aus. Der pump Befehl wird in den Hintergrund geschickt (das "&" dahinter), der blockiert nichts.

rx.sh wird offenbar gar nicht erst gestartet (habe testhalber ein readkey eingebaut, am Beginn der rx.sh).

Die rx.sh wird nicht aus der .profile gestartet, das läuft wie gesagt als service im Hintergrund. Wenn Du da ein "read" einbaust, weiss ich nicht was passiert. Dinge die als service gestartet werden haben keinerlei Verbindung zur Tastatur, laufen ja im Hintergrund. Wahrscheinlich hängt das Skript einfach weil es ewig auf eine Eingabe wartet die nie kommen kann. Oder es wird beendet weil "read" im Hintergrund eh nicht funktionieren kann.

Übrigens: hast Du irgendwas weggelassen, was für Bluetooth notwendig ist (HC-06 am GPIO ... serial ...)?

Hmm, muss ich mal schauen. Funktionieren diese Bluetooth-Serial Konverter nicht universell ohne Treiber?
Du willst damit auf die Konsole? Das geht seit 1.2 wegen dem OSD eh nicht mehr.


Edit: dt. Tastatur kannst Du mit raspi-config einstellen. Oder über SSH einloggen, dann brauchst Du nichts umstellen ...

 

[FPV-LE]

Ja, die Bluetoothdinger gehen eigentlich immer problemlos - hier aber nicht. Hab mich jetzt mit Ethernetkabel drangehangen und ssh.
Mittlerweile funktionieren TX und RX aber wie gewünscht mit Tethering aufs Handy !! Morgen dann Feld-Test, wenn das Wetter stimmt.

Was noch fehlt ist eine Funktionalität um eine unterbrochene Tether-Verbindung wieder aufzunehmen. Andererseits bootet dein Image so schnell, dass man darauf vielleicht verzichten kann.

 

[DerKlotz74]

Moin,
habe da ein Problem mit meinem ALFA...51NHV2 (Tx). Als Rx neutze ich den WDN3200.
Hatte bis vorhin das 1.0er Image drauf und da sah man immer nur Pixelbrei (Frequenz 5700MHz) bei dem ALFA. Wenn ich für Tx und Rx den WDN3200 nehme dann ist das Bild einwandfrei.
Eben bin ich auf das 1.2er Image gewechselt und da kommt nun kein Bild bei dem ALFA. Bei 2x WDN3200 ist alles gut.

Was kann ich machen? Für einen Linuxprofi wie mich bitte eine etwas genauere Anleitung bitte. Danke euch!

PiZero Tx
Pi2 Rx

 

[stxShadow]

Da ist dann ja noch jemand bei dem die Alphas mit dem neuen Image nicht funktionieren. Ggf das selbe Problem wie bei mir ?

 

[rodizio]

Hattest Du mal Deine Stromversorgung kontrolliert stxShadow? Glaube ehrlich gesagt nicht, dass da noch irgendwo ein Bug ist, gerade vor dem Hintergrund, dass Du die AWUS036NHA und DerKlotz74 die 051NH Karten nutzt (zwei völlig verschiedene Karten mit unterschiedlichen Chipsätzen).

Probiert mal das Overclocking in der config.txt rauszunehmen (vor arm_freq, over_voltage, gpu_freq, sdram_freq, force_turbo ein "#" machen).

Wenn es dann wieder funktionieren sollte, macht Eure Stromversorgung vernünftig

Wenn nicht, dann finde ich mit der Version 1.3 hoffentlich heraus woran es liegt bzw. ob da noch irgendwo ein Bug ist (die wird mehr Infos anzeigen und mehr Selbst-Checks machen um zu schauen ob alles läuft wie es soll).

Werde auch nochmal schauen, ob sich das Overclocking noch etwas entschärfen lässt um solche Probleme zu vermeiden. Wird dann aber etwas Latenz kosten. Meine persönliche Meinung ist aber trotzdem, dass wenn es nur im nicht-übertaktetem Zustand funktioniert, die Stromversorgung sowieso zu knapp dimensioniert ist.

 

[stxShadow]

Die Stromversorgung kann ich ausschließen. Läuft über ein 5 Ampere 5 volt Bec. Direkt auf den USB Port. Die 1.0er Version funktioniert ja auch einwandfrei. Bei mir gehen sowohl Sender als auch Empfänger nicht mit dem 1.2er Image. Bisher hatte ich noch keine Zeit zum Debuggen. Ich hoffe nächste Woche komme ich mal dazu. Wie gesagt: mit dem 1.0er funktioniert alles tadellos.

 

[DerKlotz74]

So,
das hat bei mir ne Menge gebracht. Lediglich bei schnellen Bewegungen ist kurzzeitig an einigen Stellen Pixelbrei.

Ich habe drei unterschiedliche Spannungsquellen an den Pi gegeben mit unterschiedlichen Resultaten.

1. Labornetzteil mit 24V über 6SBEC auf den Zero, wobei der Pi2 Rx hier auch dran hängt. Resultat wie mit dem "nichtfunktionierendem" 1.0er Image... also viel Pixelbrei
2. Powerbank (fürs Handyladen) direkt an den Zero. Deutlich weniger Pixelbrei aber dennoch unfliegbar
3. 3S Akku an 6SBEC. Hier das beste Ergebnis wie oben beschrieben.

Ich muss noch dazu sagen, dass Sender und Empfänger bei diesem Test nur 30cm auseinander waren.

 

[rodizio]

Das war alles noch in übertaktetem Zustand? Probier bitte nochmal ohne Übertaktung.

Das mit dem Pixelbrei kann glaube auch daran liegen, dass die RX sticks 'übersteuern' wenn die Highpower TX Karte zu nah ist, mach zur Sicherheit nochmal ein paar Meter dazwischen vielleicht.

Bei schnellen Bewegungen sollte aber eigentlich nix passieren vom Empfang her (wenn dabei nicht irgendwie die Antennen verdeckt oder verdreht werden etc.).


Edit: stxshadow, probier mal bitte so:

 

[DerKlotz74]

Das Ganze war schon mit runtergetaktetem PiZero.
Den Pixelbrei hatte ich auch mit dem 1.0er Image wenn ich in anderen Räumen mit meiner "besten" Spannungsversorgung unterwegs war.
Mir fällt noch ein, dass ich dem Prozessor direkt vorm Upgrade auf 1.2 einen Kühlkörper spendiert habe.

 

[rodizio]

Den Pixelbrei hatte ich auch mit dem 1.0er Image wenn ich in anderen Räumen mit meiner "besten" Spannungsversorgung unterwegs war.

Ja, das sind wahrscheinlich zwei verschiedene Probleme. Beim 1.0er ist die Sendeleistung zuweit aufgedreht, der Amp übersteuert und es kommt nichts ordentliches mehr aus der Karte heraus.

Beim 1.2er ist das nicht mehr, aber dafür kann es sein, dass die Bad blocks von der (durch das Übertakten nun stärker belasteten) einbrechenden Spannungsversorgung bzw. vom Spannungsabfall auf den Kabeln/Steckern kommen. Hab das bei den 051NH Karten mit manchen USB Kabeln beobachten können, Spannung sinkt dann an der Karte gemessen auf knapp über 4V, damit sendet die Karte zwar noch, aber nicht mehr ordentlich.