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

Status
Nicht offen für weitere Antworten.
der-Frickler

der-Frickler

Fricklomane
#141
#141
OK, seltsam das es bei dir mit dem AWUS051NH besse3r läuft. Vieleicht liegts am Channel....Bei mir gibts mit dem extrem viele bad blocks im Gegensatz zum CSL als Sender.

Ich habe am Wochenende leider nur wenig getestet. ABER: Kein einfrieren mehr mit deinen Images. Selbst wenn das Signal ganz weg war und wieder kam lief es prima weiter.
 
E

Elyot

Erfahrener Benutzer
#142
#142
Heute noch mal gleiches Setup im Büro zusammen mit einem Kollegen getestet. Distanz zwischen 3 und 5m (also näher zusammen), massive Störungen, nicht zu gebrauchen. Sticks getauscht(CSL TX, Alfa RX), astreiner Empfang. Evtl. braucht es wirklich einen Mindestabstand für die Alfas. Reflexionen könnten auch einen Einfluss haben.
 
R

rodizio

Erfahrener Benutzer
#144
#144
Hab das mit dem 051NH und 052NH nachvollziehen können, mit dem 051NH jede Menge bad blocks, mit dem 052NH geht gar nix. Bis jetzt aber nur auf 2.4g getestet. Werde schauen dass ich das gefixt kriege.

Das mit dem 'zu nah dran gibt bad blocks' bei den CSL als Empfänger scheint wirklich ein Problem mit den Sticks zu sein. Beim 722n als Empfänger kann ich die TX-Antenne bis auf ein paar mm der RX Antenne nähern, erst darunter gibts bad blocks. Beim CSL als Empfänger passiert das schon bei ca. 10cm Abstand. Je mehr Sendeleistung der TX hat, umso mehr Abstand braucht man. Scheint wohl, der Chip 'übersteuert' irgendwie bei zu hohem Signalpegel?



Ab und zu bad blocks habe ich mit den CSL sticks auch wenn WLANs in der Nähe sind (auch wenn da kaum Traffic ist), das ist bei den 722n auch besser. Da gibts erst spürbar bad blocks wenn man Traffic macht.

Edit:
Auf 5G hab ich auch in der Wohnung keine bad blocks, ins nächste Zimmer gehen klappt auch mit den mitgelieferten 2.4g Antennen problemlos.
 
Zuletzt bearbeitet:
S

stxShadow

Erfahrener Benutzer
#145
#145
Das Problem mit dem übersteuern kann ich bestätigen. Dazu gab es in dem anderen Thread schon eine Diskussion. Ich sehe das extrem bei meiner 16turn Helix. Wenn ich näher als 40m dran bin geht nix mehr. Prima wäre es, wenn das System beim überschreiten eines bestimmten Antennenwertes, diesen Empfänger ggf blockt und nur die Bilder eines anderen nimmt. Bei mir gibt es 2x 051NH ... Einmal mit spw und einmal mit Helix. ..... Zu nah dran dann nur die SPW
 
R

rodizio

Erfahrener Benutzer
#146
#146
Hab das zwar nicht explizit getestet, aber eigentlich sollte das bei meinem Image automatisch passieren. Wenn an einer Karte nur kaputte (=mit fehlerhafter FCS) Pakete ankommen müssten die einfach alle weggeworfen werden.
 
ApoC

ApoC

Moderator
#147
#147
Hab heute nochmal getestet.

Kurz nochmal zum System.

TX: Rpi2 mit WN722 Stick
RX: Rpi2 mit 2 x WN722

Standard Einstellungen vom Image. Keine Änderungen gemacht.

Ich habe bisher am RX ohne Diversity getestet, alles gut. Sobald ich jedoch den 2. Stick am RX anschliesse, hab ich nurnoch Bad Blocks.

Nehme ich die beiden Sticks jeweils EINZELN, also ohne Diversity, haut alles hin.

Habt ihr ne Idee dazu?

2. Frage: Kann man das OSD mit aufnehmen? Im aufgenommenen Video ist es leider nicht zu sehen - würde das aber gern im Video sehen, zur Analyse.

Sind ja noch in der Testphase, da ist Wissen alles. ;)
 
ApoC

ApoC

Moderator
#150
#150
brandtaucher hat gesagt.:
Wenn ich zwei csl300 nehme, habe ich auch jede Menge bad blocks. Aber trotzdem ein flüssiges Bild. Hast Du kein Bild?
Zum Vergrößern anklicken....
Ich hab dann massive Bildstörungen, auch wenn ich die Sticks untereinander tausche.

Gesendet von meinem E6653 mit Tapatalk
 
R

rodizio

Erfahrener Benutzer
#151
#151
Hmm, das ist seltsam. Hatte RX Diversity mit 3 CSL sticks getestet, das funktionierte wenn ich mich recht entsinne.

Mir würde jetzt erstmal nur zuviel CPU-Last mit zwei Sticks als Ursache einfallen, aber mit einem Pi2 sollte das eigentlich kein Problem sein.
Könnt ihr mal zur Sicherheit "top" aufrufen und schauen ob irgendein Prozess ("rx" wahrscheinlich) viel Last macht?
 
der-Frickler

der-Frickler

Fricklomane
#152
#152
rodizio hat gesagt.:
Hmm, das ist seltsam. Hatte RX Diversity mit 3 CSL sticks getestet, das funktionierte wenn ich mich recht entsinne. Mir würde jetzt erstmal nur zuviel CPU-Last mit zwei Sticks als Ursache einfallen, aber mit einem Pi2 sollte das eigentlich kein Problem sein. Könnt ihr mal zur Sicherheit "top" aufrufen und schauen ob irgendein Prozess ("rx" wahrscheinlich) viel Last macht?
Zum Vergrößern anklicken....
Wie gesagt, bei mir laufen 2 CSL300 prima am Zero v1 als RX mit deinem Image. Bad Blocks gibts nur mit dem Alpha als TX, WDM3200 und CSL300 als TX funktionieren.
 
ApoC

ApoC

Moderator
#153
#153
So, heute nochmal aufm Feld, jenseits von störenden WLANs getestet. (nur 2,4Ghz wegen der WN722).

Ich habe beim Diversity immernoch Störungen, bzw Bad Blocks. Nutze ich nur einen Stick als RX, ist alles fein. Weiterhin friert das Bild ein - also es ist da, aber es bewegt sich nicht mehr.
Mit nur einem Stick am TX/RX war die Reichweite enorm. Ich war ca 1,7km weg vom TX und hatte noch immer glasklares Bild. Bis auf ein paar Störungen am unteren Bildrand, die ab und zu mal aufkamen. Aber das hab ich auch, wenn ich TX und RX 1m zusammenstelle. ;) (PS: Sogar auf den DJI Phantom 4 Videos sieht man sowas oft, scheint also normal zu sein. ;) )

Getestet mit Stock Stabantennen und 2 SPWs jeweils am RX / TX.

Hatte auchn Pi1 als RX und TX verwendet, gleiches Spiel. TOP zeigt keine Auffälligkeiten am TX/RX.
Wenn das beim Frickler geht, muss bei mir ja irgendwo der Wurm drin sein.

Keine Ahnung, was da los ist.

Wichtige Frage: Ich möchte natürlich einen digitalen Bildschirm in meine Quanum V2 einbauen, welcher dann auch für das WBC funktioniert. Gefunden habe ich 800x600 Aufsteck TFTs für den Pi - und natürlich normale 5" Bildschirme mit HDMI usw.

Habt ihr n Tip für einen guten 5" Bildschirm, der auch die Auflösung schafft und in die Quanum passt? Darf halt maximal 5" haben aber sollte eben das bestmögliche Bild hergeben.
 
R

rodizio

Erfahrener Benutzer
#154
#154
Hmm, seltsam mit der Diversity-Geschichte. Muss ich mal drüber nachdenken wie man das noch weiter eingrenzen könnte.

Wegen der kurzen Störungen könntest Du mal andere FEC Werte probieren:
BLOCK_SIZE=16
FECS=12
PACKET_LENGTH=512
 
brandtaucher

brandtaucher

Erfahrener Benutzer
#155
#155
Habe nun einen Pi Zero und eine Raspicam und versuche das als TX einzurichten (vorher immer Raspi vom Freund als TX genommen). Ich kriege es einfach nicht zum laufen. Schließt man zusätzlich einen Monitor an, sieht an Wifibroadcam (Schriftzug) und anschließend dauerhaft in der ersten PI@Wifibroadcast:" $ oder so ähnlich. Aber das Bild ist schwarz.
Habe auch schon den Zero als Empfänger eingerichtet und den den B+ als Sender, aber es ist das gleiche. Schriftzüge aber kein Kamerabild. Hat jemand eine Idee oder sogar das gleiche Problem gehabt?

Edit: Nachdem ich systematisch vorgegangen bin, den Zero mit Noobs getestet habe, die Camera einzeln in Betrieb genommen habe und mir dabei auffiel, dass eine Maus oder eine Tastatur über den USB-Port auch nicht funktioniert, kam mir in den Sinn, dass was mit dem USB-Port nicht geht.

Ich habe mit Adaptern gearbeitet, aber irgendwie funzt das nicht. Also gem. USB-Hack eine USB-Buchse direkt angelötet und nun klappt es!

Hier der Link dazu:

https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=127449

siehe Beitrag:

by yy502 » Sun Feb 28, 2016 11:25 pm




Meine steckbare Lösung:

01465151232207.jpg
 
Zuletzt bearbeitet:
R

rodizio

Erfahrener Benutzer
#156
#156
Hmm, werde mal schauen dass ich noch ein paar Status-Infos am TX ausgebe, sodass man sieht ob die Karten etc. richtig erkannt wurden ...

Habe auch allg. die Erfahrung gemacht dass diverse USB-Adapter und Kabel am Pi nicht vernünftig funktionieren. Am besten alles fest verlöten oder vernünftige Stecker (Balancer-Stecker oder sowas, nur nicht USB).

Den Pi Zero kann man wie die alten A Modelle übrigens auch über USB versorgen, glaube das ist beim TX am besten, so geht der Strom für die WLAN Karte nicht über den Pi.



Ansonsten habe ich gerade V1.1 Beta hochgeladen.

Folgende Änderungen:

- Befi's und Rangarid's OSD integriert (ungetestet!)
- Raspbian Update auf Kerne 4.11 und neuere Raspberry Firmware / Userland
- USB Ethernet Tethering Unterstützung im Kernel wieder aktiviert
- DHCP auf Netzwerkschnittstelle aktiviert
- Anzeige der konfigurierten Frequenz/FEC-Werte in der untersten Zeile
- video.c geändert für bis zu 90fps
- Bash-prompt zeigt nun ro/rw filesystem an, Makros (rw,ro) hinzugefügt zum umschalten
- performance governor defaultmässig aktiviert
- force_turbo aktiviert
- Sendeleistung für Ralink Chipsätze stark reduziert (AWUSH051NH und 052NH haben Probleme gemacht)
- Sendeleistung für Atheros Chipsätze leicht reduziert (nur zur Sicherheit)
- Atheros Firmware für weitere Atheros Chipsätze gepatcht (AR9287, TPLink 822N V2 z.B.)
- Getestet mit AWUS036NH, AWUS036NHA, AWUS051NH, TL-WN722N, TL-WN822N V2, CSL 300Mbit
- V2 Cam mit bis zu 68fps getestest



Ist noch nicht wirklich grossartig getestet, deswegen "Beta".
Testet bitte erstmal sorgfältig ob ohne OSD alles sauber läuft.

http://en.file-upload.net/download-11650538/ez-wifibroadcast-1.1beta.zip.html
 
der-Frickler

der-Frickler

Fricklomane
#160
#160
So, Images mal fix indoor getestet! LÄUFT jetzt auch mit dem Alpha AWUS051NH.

Mit WDN3200 und CSL300 so -50db mit dem Alpha -30db. Wie gesagt, nur Indoor fix in 4m Abstand, denke man sieht aber schon den Unterschied in der Sendeleistung.

OSD noch ungetestet bis dato.
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten