FPV Wifi Broadcasting HD Video - Thread zum Raspberry HD Videolink von Befi
- Themenstarter trailblazer
- Beginndatum
- Status
Was ist eigentlich von solchen Wifi Boostern zu halten?
Würden die auch bei unserem Projekt funktionierten?
http://www.ebay.de/itm/2-4-GHz-4W-w...656651?hash=item1c5591188b:g:4-8AAOSwll1WwZH6
Ja, 4W sind nicht mehr erlaubt, aber immerhin hätte man so die Reichweitenprobleme beseitigt
Und noch ne frage,
wenn man jetzt als Rx ein Pc benutzt, ist es dann auch möglich das 2.3ghz Netz zu verwenden?
Oder geht das nur mit nem Pi?
Würden die auch bei unserem Projekt funktionierten?
http://www.ebay.de/itm/2-4-GHz-4W-w...656651?hash=item1c5591188b:g:4-8AAOSwll1WwZH6
Ja, 4W sind nicht mehr erlaubt, aber immerhin hätte man so die Reichweitenprobleme beseitigt
Und noch ne frage,
wenn man jetzt als Rx ein Pc benutzt, ist es dann auch möglich das 2.3ghz Netz zu verwenden?
Oder geht das nur mit nem Pi?
Zuletzt bearbeitet:
2.3G geht auch auf einem PC, musst Dir allerdings selbst die Kernelmodule patchen und kompilieren.
Diese billigen Booster sind praktisch immer übertrieben von den Leistungsangaben und rauschen stark wenn man sie weiter aufdreht. Der im ebay Link widerspricht sich schon im Datenblatt, 13db gain, 36dbm Ausgangsleistung und max. Eingangsleistung 20dbm, ähm ja
In der Praxis kommst Du damit vielleicht bei ca. 3db mehr raus als mit einem AWUS036NHA und das auch nur wenn Du die Sendeleistung des Sticks davor genau so einstellst, dass der billige Amp das Signal gerade nicht zuviel verschlechtert ...
Da gibt's echt tausend bessere Methoden die Reichweite zu erhöhen, abgesehen davon, mit dem AWUS036NHA sind schon mehrere km geflogen worden, das sollte wohl locker reichen.
Diese billigen Booster sind praktisch immer übertrieben von den Leistungsangaben und rauschen stark wenn man sie weiter aufdreht. Der im ebay Link widerspricht sich schon im Datenblatt, 13db gain, 36dbm Ausgangsleistung und max. Eingangsleistung 20dbm, ähm ja
In der Praxis kommst Du damit vielleicht bei ca. 3db mehr raus als mit einem AWUS036NHA und das auch nur wenn Du die Sendeleistung des Sticks davor genau so einstellst, dass der billige Amp das Signal gerade nicht zuviel verschlechtert ...
Da gibt's echt tausend bessere Methoden die Reichweite zu erhöhen, abgesehen davon, mit dem AWUS036NHA sind schon mehrere km geflogen worden, das sollte wohl locker reichen.
Was ist eigentlich von solchen Wifi Boostern zu halten?
Würden die auch bei unserem Projekt funktionierten?
http://www.ebay.de/itm/2-4-GHz-4W-w...656651?hash=item1c5591188b:g:4-8AAOSwll1WwZH6
Ja, 4W sind nicht mehr erlaubt, aber immerhin hätte man so die Reichweitenprobleme beseitigt
Und noch ne frage,
wenn man jetzt als Rx ein Pc benutzt, ist es dann auch möglich das 2.3ghz Netz zu verwenden?
Oder geht das nur mit nem Pi?
Würden die auch bei unserem Projekt funktionierten?
http://www.ebay.de/itm/2-4-GHz-4W-w...656651?hash=item1c5591188b:g:4-8AAOSwll1WwZH6
Ja, 4W sind nicht mehr erlaubt, aber immerhin hätte man so die Reichweitenprobleme beseitigt
Und noch ne frage,
wenn man jetzt als Rx ein Pc benutzt, ist es dann auch möglich das 2.3ghz Netz zu verwenden?
Oder geht das nur mit nem Pi?
Ich würd's auch lassen, denn auch in CH ist das Frequenzband an eine terristrische Anwendung geknüpft. Da spielt es keine Rolle ob man es WLAN nennt oder sonst ein Protokoll verwendet. Zumindest habe ich vom zuständigen Amt in der CH die mündliche Aussage, dass sie bei dieser Nutzung eine Ausnahme machen würden. Aber eben - schriftlich habe ich das nicht bestätigt gekriegt. Sagt auch schon was.
Weiter machen - wir sind keine Juristen sondern wollen fliegen gehen und Spass haben.
Weiter machen - wir sind keine Juristen sondern wollen fliegen gehen und Spass haben.
RPi Zero V1.3 HAT mit 5V/3A BEC (8-42V Input) und USB A-Buchse/UART
Hier mal meine 'Interpretation' eines TX und RX:
Ich wollte keine Kabel anlöten und so kompakt wie möglich bauen (Bild zeigt den ersten Testaufbau mit 12mm Abstandsbolzen; wird auf 8mm reduziert). Das abgebildete Set wird noch um ein 5in TFT (800x480pixel) ergänzt welches direkt über das DPI-Interface des Raspberry angesteuert wird. Die einzigen Kabel sind dann die Stromversorgung (8V - 42V) und das FFC zum Display. Alles wird auf einer Trägerplatte aus GFK montiert und kommt in meine Quanum V2 (auf dem Zero läuft übrigens auch das Autoquad QGC; langsam aber es geht).
Beim TX wird natürlich keine Stiftleiste bestückt, vielmehr kommen noch zwei weitere Pogo-Pins rein die dann die UART mit der ZH-Buchse verbinden.
Hier mal meine 'Interpretation' eines TX und RX:
Ich wollte keine Kabel anlöten und so kompakt wie möglich bauen (Bild zeigt den ersten Testaufbau mit 12mm Abstandsbolzen; wird auf 8mm reduziert). Das abgebildete Set wird noch um ein 5in TFT (800x480pixel) ergänzt welches direkt über das DPI-Interface des Raspberry angesteuert wird. Die einzigen Kabel sind dann die Stromversorgung (8V - 42V) und das FFC zum Display. Alles wird auf einer Trägerplatte aus GFK montiert und kommt in meine Quanum V2 (auf dem Zero läuft übrigens auch das Autoquad QGC; langsam aber es geht).
Beim TX wird natürlich keine Stiftleiste bestückt, vielmehr kommen noch zwei weitere Pogo-Pins rein die dann die UART mit der ZH-Buchse verbinden.
Habe mal den Datendurchsatz CSL300Mbit gegen TPLink 722N auf 2.4G mit 24Mbit Datenrate verglichen. Jeweils die Netto-Datenrate die mit Standard FEC Settings (8/4/1024) zur Verfügung steht, die Videbitrate muss wegen Schwankungen etc. nochmal ungefähr halbiert werden.
TPLink: 9.9Mbit
CSL: 11.4Mbit
Irgendwie scheint das an den Interframe Spacings in den Treibern zu liegen, habe das bei beiden mal etwas frisiert, dann kommt das heraus:
TPLink: 11.3Mbit
CSL: 11.9Mbit
CSL immer noch besser und mit kleineren Paketgrössen wird der Abstand immer grösser. Irgendwas muss sich da hoffentlich noch optimieren lassen ...
TPLink: 9.9Mbit
CSL: 11.4Mbit
Irgendwie scheint das an den Interframe Spacings in den Treibern zu liegen, habe das bei beiden mal etwas frisiert, dann kommt das heraus:
TPLink: 11.3Mbit
CSL: 11.9Mbit
CSL immer noch besser und mit kleineren Paketgrössen wird der Abstand immer grösser. Irgendwas muss sich da hoffentlich noch optimieren lassen ...
Der Tipp hilft leider eben gerade nicht, habe mich von dem Thread und vielen anderen Beiträgen auch erst in die Irre führen lassen, dass es ein Stromproblem ist. Am Ende war es ab klar nachvollziehbar ein Spannungsproblem, also erst ab 5.3V. Naja, hat sich eh erledigt, habe einen Pi Zero ergattert .
.Habe mal den Datendurchsatz mit verschiedenen Taktraten auf einem Pi1 als TX gemessen. Angaben sind jeweils in Megabyte/s.
"Stabil" oder "Schwankend" heisst die Datenrate schwankt stark. Bin mir nicht ganz sicher warum das so ist, ich schätze weil cat einfach "volle Pulle" in den TX Prozess schickt, dann irgendwann irgendwelche Buffer voll werden die dann wieder geflushed werden müssen. Zumindestens scheint das regelmässiger Natur zu sein, CPU Last geht dann auch zeitweise hoch wenn die Datenrate runter geht.
Das muss bei Benutzung mit raspivid als Datenquelle nicht unbedingt ein Problem sein, weil das ja normalerweise nicht schneller sendet als der tx Prozess Daten los wird. So ganz vertrauenserweckend ist das aber irgendwie nicht. Auf einem Pi2 ist das nicht der Fall.
Nächstes Problem ist, dass die raspivid Datenrate doch nicht so konstant ist wie man meinen könnte, d.h. man braucht zur Sicherheit grob das doppelte an Datendurchsatz auf WLAN Seite als die raspivid Bitrate wenn man nicht mit plötzlich steigender Latenz bei plötzlichen Szenenwechseln mit stärkeren Beleuchtungsunterschieden leben möchte.
Wenn man sich das jetzt für 24Mbit mit 1024/8/4 (den Standardsettings) und 5Mbit Videobitrate anschaut, dann sieht das gar nicht mehr so gut aus 5Mbit * 2 / 8 wären 1.25 Megabyte/s die man auf WLAN Seite braucht. Die gehen auf einem Pi Zero gerade eben so, auf einem Pi1/Odroid-W gar nicht. Das ist aber immer mit 100% CPU Auslastung, was man vermeiden sollte, sonst gibt's wieder unkontrolliert steigende Latenz.
Alle tests mit:
ifconfig wlan0 down && iwconfig wlan0 mode monitor && ifconfig wlan0 up && iwconfig wlan0 channel 13
cat /dev/zero | pv -r -a -T -i 0.1 | /home/pi/wifibroadcast/tx -p 0 -b 8 -r 4 -f 1024 wlan0 > /dev/null
arm 700, gpu 250, sdram 400 (Pi1/Odroid-W Serienzustand)
1.18MiB mit 1024/8/4 auf 54M schwankend
1.16MiB mit 1024/8/4 auf 36M schwankend
1.10MiB mit 1024/8/4 auf 24M schwankend
1.05MiB mit 1024/8/4 auf 18M schwankend
arm 1000, gpu 250, sdram 400 (Pi Zero Serienzustand)
1.40MiB mit 1024/8/4 auf 54M schwankend
1.30MiB mit 1024/8/4 auf 36M schwankend
1.25MiB mit 1024/8/4 auf 24M schwankend
1.10MiB mit 1024/8/4 auf 18M schwankend
arm 1000, gpu 400, sdram 433:
1.7MiB mit 1024/8/4 auf 54M schwankend
1.4MiB mit 1024/8/4 auf 24M schwankend
arm 1000, gpu 450, sdram 450:
1.8MiB mit 1024/8/4 auf 54M schwankend
1.4MiB mit 1024/8/4 auf 24M schwankend
arm 1100, gpu 400, sdram 433:
1.78MiB mit 1024/8/4 auf 54M schwankend
1.70MiB mit 1024/8/4 auf 36M schwankend
1.41MiB mit 1024/8/4 auf 24M schwankend
1.16MiB mit 1024/8/4 auf 18M stabil
arm 1100, gpu 450, sdram 433:
1.82MiB mit 1024/8/4 auf 54M schwankend
1.78MiB mit 1024/8/4 auf 36M schwankend
1.42MiB mit 1024/8/4 auf 24M schwankend
1.16MiB mit 1024/8/4 auf 18M stabil
arm 1100, gpu 500 sdram 466:
1.95MiB mit 1024/8/4 auf 54M schwankend
1.90MiB mit 1024/8/4 auf 36M schwankend
1.45MiB mit 1024/8/4 auf 24M schwankend
1.16MiB mit 1024/8/4 auf 18M stabil
arm 1100, gpu 550 sdram 466:
1.96MiB mit 1024/8/4 auf 54M schwankend
1.88MiB mit 1024/8/4 auf 36M schwankend
1.46MiB mit 1024/8/4 auf 24M schwankend
1.16MiB mit 1024/8/4 auf 18M stabil
Zum Vergleich auf einem Pi2:
2.61MiB mit 1024/8/4 auf 54M stabil
1.99MiB mit 1024/8/4 auf 36M stabil
1.47MiB mit 1024/8/4 auf 24M stabil
1.16MiB mit 1024/8/4 auf 18M stabil
"Stabil" oder "Schwankend" heisst die Datenrate schwankt stark. Bin mir nicht ganz sicher warum das so ist, ich schätze weil cat einfach "volle Pulle" in den TX Prozess schickt, dann irgendwann irgendwelche Buffer voll werden die dann wieder geflushed werden müssen. Zumindestens scheint das regelmässiger Natur zu sein, CPU Last geht dann auch zeitweise hoch wenn die Datenrate runter geht.
Das muss bei Benutzung mit raspivid als Datenquelle nicht unbedingt ein Problem sein, weil das ja normalerweise nicht schneller sendet als der tx Prozess Daten los wird. So ganz vertrauenserweckend ist das aber irgendwie nicht. Auf einem Pi2 ist das nicht der Fall.
Nächstes Problem ist, dass die raspivid Datenrate doch nicht so konstant ist wie man meinen könnte, d.h. man braucht zur Sicherheit grob das doppelte an Datendurchsatz auf WLAN Seite als die raspivid Bitrate wenn man nicht mit plötzlich steigender Latenz bei plötzlichen Szenenwechseln mit stärkeren Beleuchtungsunterschieden leben möchte.
Wenn man sich das jetzt für 24Mbit mit 1024/8/4 (den Standardsettings) und 5Mbit Videobitrate anschaut, dann sieht das gar nicht mehr so gut aus
5Mbit * 2 / 8 wären 1.25 Megabyte/s die man auf WLAN Seite braucht. Die gehen auf einem Pi Zero gerade eben so, auf einem Pi1/Odroid-W gar nicht. Das ist aber immer mit 100% CPU Auslastung, was man vermeiden sollte, sonst gibt's wieder unkontrolliert steigende Latenz.Alle tests mit:
ifconfig wlan0 down && iwconfig wlan0 mode monitor && ifconfig wlan0 up && iwconfig wlan0 channel 13
cat /dev/zero | pv -r -a -T -i 0.1 | /home/pi/wifibroadcast/tx -p 0 -b 8 -r 4 -f 1024 wlan0 > /dev/null
arm 700, gpu 250, sdram 400 (Pi1/Odroid-W Serienzustand)
1.18MiB mit 1024/8/4 auf 54M schwankend
1.16MiB mit 1024/8/4 auf 36M schwankend
1.10MiB mit 1024/8/4 auf 24M schwankend
1.05MiB mit 1024/8/4 auf 18M schwankend
arm 1000, gpu 250, sdram 400 (Pi Zero Serienzustand)
1.40MiB mit 1024/8/4 auf 54M schwankend
1.30MiB mit 1024/8/4 auf 36M schwankend
1.25MiB mit 1024/8/4 auf 24M schwankend
1.10MiB mit 1024/8/4 auf 18M schwankend
arm 1000, gpu 400, sdram 433:
1.7MiB mit 1024/8/4 auf 54M schwankend
1.4MiB mit 1024/8/4 auf 24M schwankend
arm 1000, gpu 450, sdram 450:
1.8MiB mit 1024/8/4 auf 54M schwankend
1.4MiB mit 1024/8/4 auf 24M schwankend
arm 1100, gpu 400, sdram 433:
1.78MiB mit 1024/8/4 auf 54M schwankend
1.70MiB mit 1024/8/4 auf 36M schwankend
1.41MiB mit 1024/8/4 auf 24M schwankend
1.16MiB mit 1024/8/4 auf 18M stabil
arm 1100, gpu 450, sdram 433:
1.82MiB mit 1024/8/4 auf 54M schwankend
1.78MiB mit 1024/8/4 auf 36M schwankend
1.42MiB mit 1024/8/4 auf 24M schwankend
1.16MiB mit 1024/8/4 auf 18M stabil
arm 1100, gpu 500 sdram 466:
1.95MiB mit 1024/8/4 auf 54M schwankend
1.90MiB mit 1024/8/4 auf 36M schwankend
1.45MiB mit 1024/8/4 auf 24M schwankend
1.16MiB mit 1024/8/4 auf 18M stabil
arm 1100, gpu 550 sdram 466:
1.96MiB mit 1024/8/4 auf 54M schwankend
1.88MiB mit 1024/8/4 auf 36M schwankend
1.46MiB mit 1024/8/4 auf 24M schwankend
1.16MiB mit 1024/8/4 auf 18M stabil
Zum Vergleich auf einem Pi2:
2.61MiB mit 1024/8/4 auf 54M stabil
1.99MiB mit 1024/8/4 auf 36M stabil
1.47MiB mit 1024/8/4 auf 24M stabil
1.16MiB mit 1024/8/4 auf 18M stabil
Umgekehrt: wenn man die WLAN-Sende-Antenne in die Nähe des Raspis hält, kriegt der Raspi Probleme...
Hier mein Testaufbau (tx):
Wenn die Antenne zu nah am Raspi ist, stockt die Bildübertragung. Es gehen aber keine Bilder verloren, sondern werden mit starker Latenz "nach-geliefert". Erklärung unklar.
Schirmen ist aber eine gute Idee. Ich denke ich setze den Raspi auch ins Untergeschoss des Copters...
Hier mein Testaufbau (tx):
Wenn die Antenne zu nah am Raspi ist, stockt die Bildübertragung. Es gehen aber keine Bilder verloren, sondern werden mit starker Latenz "nach-geliefert". Erklärung unklar.
Schirmen ist aber eine gute Idee. Ich denke ich setze den Raspi auch ins Untergeschoss des Copters...
Zuletzt bearbeitet:
Mit diesem (Test-)Aufbau hatte ich massive Probleme:
Der Odroid-W ist mit dem TPLink-Stick als Heißkleber-Sandwich oben-vorne verbaut. Die Antenne war zum testen noch direkt aufgesteckt. Wie gesagt, der Raspi wurde massiv gestört.
Mittlerweile habe ich die Antenne über ein RP-SMA Kabel an die Spitze verlegt. Seitdem sind die Probleme verschwunden.
Es kommt also wirklich auf cm an (wegen R^2).
Mein erster Flug endete trotzdem im Disaster. Nach 30 Sekunden gehen im Steigflug alle Motoren aus (Failsafe von vom FrSky-Receiver?), und der Copter fällt wie ein Stein vom Himmel in die Wiese, trotz 2.3 Ghz Band. Video-Übertragung war dafür stabil bis bei der Landung die Antenne angebrochen ist ;-(
Bin danach noch die Batterie ohne Video leer geflogen - keine Probleme mehr. Das macht mich etwas nervös.
Die defekte WLAN-Antenne habe ich mal komplett vom Plastik befreit. Es kamm ein flexibles Stahlband zum Vorschein, welches ich noch mit Schrumpfschlauch geschützt habe. Gefällt mir viel besser als das Original und sollte beim Sturz jetzt nachgeben.
Der Odroid-W ist mit dem TPLink-Stick als Heißkleber-Sandwich oben-vorne verbaut. Die Antenne war zum testen noch direkt aufgesteckt. Wie gesagt, der Raspi wurde massiv gestört.
Mittlerweile habe ich die Antenne über ein RP-SMA Kabel an die Spitze verlegt. Seitdem sind die Probleme verschwunden.
Es kommt also wirklich auf cm an (wegen R^2).
Mein erster Flug endete trotzdem im Disaster. Nach 30 Sekunden gehen im Steigflug alle Motoren aus (Failsafe von vom FrSky-Receiver?), und der Copter fällt wie ein Stein vom Himmel in die Wiese, trotz 2.3 Ghz Band. Video-Übertragung war dafür stabil bis bei der Landung die Antenne angebrochen ist ;-(
Bin danach noch die Batterie ohne Video leer geflogen - keine Probleme mehr. Das macht mich etwas nervös.
Die defekte WLAN-Antenne habe ich mal komplett vom Plastik befreit. Es kamm ein flexibles Stahlband zum Vorschein, welches ich noch mit Schrumpfschlauch geschützt habe. Gefällt mir viel besser als das Original und sollte beim Sturz jetzt nachgeben.
- Status
