EZ-Wifibroadcast, HD FPV in günstig und einfach
- Themenstarter rodizio
- Beginndatum
- Status
Das ist doch fein. Der B101 ist zwar ziemlich zickig, was 1080 angeht, aber mit 720p läuft der hier bei mir an einer Nex5 und am HDMI-Ausgang eines anderen PIs sehr zuverlässig. Manchmal ist die Einschaltreihenfolge hakelig, und es funktioniert bei mir grundsätzlich nur nach einem Reboot (trotz GPIO-Reset des B101, wie in der Doku beschrieben, aber das klappt bei mir einfach nicht). Aber damit kann ich leben, denn am Kopter tausche ich die Cam ja nicht im laufenden Betrieb.
Ansonsten finde ich das Konzept nach wie vor toll, weil ich eben z.B. auch beliebig viele kleine unabhängige "Simultanempfänger" aufbauen kann. Ich setze das z.B. bei der Kitzrettung ein, da macht das sehr viel Sinn.
Viele Grüße,
Stefan
Ansonsten finde ich das Konzept nach wie vor toll, weil ich eben z.B. auch beliebig viele kleine unabhängige "Simultanempfänger" aufbauen kann. Ich setze das z.B. bei der Kitzrettung ein, da macht das sehr viel Sinn.
Viele Grüße,
Stefan
Ok, also einziger Unterschied scheint dann die Android Version zu sein, ich hab noch 4.4 am Tablet. Deine SR schauen OK aus, zumindest müssten auch die Parameter übertragen werden.
Ich hab mir jetzt einzelne Pakete die am Tablet ankommen angesehen, beispielsweise das SYS_STATUS. Das ist bis hin zur CRC (die hab ich nicht nachgerechnet) in Ordnung. Prüft das OSD eigentlich die CRC? Ansonsten wüsste ich jetzt nicht warum Tower nichts damit anfängt aber das OSD korrekt angezeigt wird.
PS: GPIO +5V mit dem Testpunkt für USB Power zu verlöten hat die Versorgungsprobleme gelöst, läuft auch ohne USB Hub und lädt gleich das Tablet.
Ich hab mir jetzt einzelne Pakete die am Tablet ankommen angesehen, beispielsweise das SYS_STATUS. Das ist bis hin zur CRC (die hab ich nicht nachgerechnet) in Ordnung. Prüft das OSD eigentlich die CRC? Ansonsten wüsste ich jetzt nicht warum Tower nichts damit anfängt aber das OSD korrekt angezeigt wird.
PS: GPIO +5V mit dem Testpunkt für USB Power zu verlöten hat die Versorgungsprobleme gelöst, läuft auch ohne USB Hub und lädt gleich das Tablet.
Das OSD nutzt den "offiziellen" Mavlink parser, ich schätze mal der prüft die CRC. Kannst Du mal in der telemetry.txt und .raw (und auch auf dem Tablet) schauen ob da Mavlink Heartbeats ankommen? Glaube bei deepflights war das auch seltsam, in der .raw waren die Heartbeats drin, aber nicht in der .txt, d.h. der parser hat die Messages irgendwie nicht erkannt.
Bin mir nicht sicher, aber ich glaube irgendwer sagte die ganzen GCS Tools wie Tower und Missionplanner hören erstmal nur auf Heartbeats, wenn die nicht kommen zeigen sie auch den Rest nicht an.
Bin mir nicht sicher, aber ich glaube irgendwer sagte die ganzen GCS Tools wie Tower und Missionplanner hören erstmal nur auf Heartbeats, wenn die nicht kommen zeigen sie auch den Rest nicht an.
War das auf einem freien Kanal, bzw. hattest Du wärend des Tests packetloss? Bei den Telemetrie-Paketen gibt's keinerlei FEC, von daher bedeutet packetloss (zuhause mit anderen WLANs in der Nähe) bei der Telemetrie auch direkt verlorene Telemetrie Pakete (wahrscheinlich sind die mit den kaputten CRCs abgeschnittene Mavlink messages).
Aber hilft alles nicht, bevor die Mavlink Messages nicht vernünftig 1:1 in wbc Pakete gepackt werden lohnt weiteres drüber Nachdenken nicht ...
Hier noch Bilder vom letzten Test mit 25mW 5.8Ghz, TX CSL-300 Mbit stick mit Connex Prosight Antennen, RX 2x CSL-300 Mbit sticks mit den WA5VJB single patches. Entfernung zwischen TX und RX auf der Brücke 620m.
Careyer: Hier noch zwei Bilder:
Aber hilft alles nicht, bevor die Mavlink Messages nicht vernünftig 1:1 in wbc Pakete gepackt werden lohnt weiteres drüber Nachdenken nicht ...
Hier noch Bilder vom letzten Test mit 25mW 5.8Ghz, TX CSL-300 Mbit stick mit Connex Prosight Antennen, RX 2x CSL-300 Mbit sticks mit den WA5VJB single patches. Entfernung zwischen TX und RX auf der Brücke 620m.
Careyer: Hier noch zwei Bilder:
Falls jemand die neusten Änderungen am Kernel testen will:
https://github.com/bortek/EZ-WifiBroadcast/issues/21
https://github.com/bortek/EZ-WifiBroadcast/issues/21
Kurze Frage das ich das Thema was aus den Augen verloren hatte:
Wird der Raspi Zero W bzw dessen integriertes WLAN als Sender unterstützt?
P.S. Ja, ich weiß, der Zero is eh am Limit als Sender und das integrierte WLAN wird von der Reichweite her nicht toll sein, wollte evtl nur mal was kleines versuchen. Antenne läßt sich ja mit kleiner Änderung ne externe anklemmen.
Wird der Raspi Zero W bzw dessen integriertes WLAN als Sender unterstützt?
P.S. Ja, ich weiß, der Zero is eh am Limit als Sender und das integrierte WLAN wird von der Reichweite her nicht toll sein, wollte evtl nur mal was kleines versuchen. Antenne läßt sich ja mit kleiner Änderung ne externe anklemmen.
Bedankt rodizio, 620m bei 0 BadBlocks und nur 14 lost Packets - RESPEKT!
Habe am WE auch ein paar Tests durchgeführt - allerdings mitten in der Stadt, d.h. in völlig WLAN verseuchtem Gebiet (Gott ist das schlimm... wenn man mal mit nem Scanner rumläuft will man nachher nur noch mit Aluminiumfolie um den Kopf rumlaufen ;-).
Test1: (2,4Ghz)
TX: 1x Alfa 036NHA, 5dbi Stock Antenna, auf dem Balkon 3.OG
RX: 2x TP-Link 722N mit je 1x Alfa 7db Patch Antennen, (in der Hand mit rumgelaufen)
Ergebnis: 450m fliegbar, bis 300m weitestgehend stabiles Signal (immer mal wieder kleinere Glitches, nix Wildes), >300m keine direkte Sichtverbindung mehr (Abschattung durch Baumkronen einer nahegelegenen Allee und Funkschatten durch Hauswände umliegender hoher Gebäude). Signal "kam trodem noch recht gut durch".
Test2: (5,8Ghz)
TX: 1x Alfa 052NH, 2x 5dbi Stock Antennen, auf dem Balkon 3.OG
RX: 2x CSL-300 mit jeweils 1x Stock Antenna (eig. 2,4Ghz) und 1x Alfa 7db Patch Dualband-Antenne,
Ergebnis: bis 300m absolut sauberes Signal, keine Störungen, keine Glitches.... danach machte der Weg eine leichte Biegung und die direkte Sichtverbindung geht verloren (s.o., Abschattung durch Allee und Hauswände) - Resultiert in akutem Verbindungsabriss. Erstaunlich: Verbindung ließ sich teils wiederherstellen indem man andere Hauswände als Reflektionsflächen genutzt hat! Sehr geil!!! - quasi: WiFi-Broastcast-Billard. Das ging sogar hinter(!!!) unserem 4 stöckigen Wohnhaus. Da sieht man mal, wie hohe Frequenzen sich zunhemend wie Licht verhalten. Konnte man eine Reflektionsfläche sehen, dann gabs auch ein sauberes Signal wenn man die Patch-Antennen drauf ausgerichtet hat. Irre!
Bin auf erste Tests auf freiem Feld gespannt.
Good Work!!!
Habe am WE auch ein paar Tests durchgeführt - allerdings mitten in der Stadt, d.h. in völlig WLAN verseuchtem Gebiet (Gott ist das schlimm... wenn man mal mit nem Scanner rumläuft will man nachher nur noch mit Aluminiumfolie um den Kopf rumlaufen ;-).
Test1: (2,4Ghz)
TX: 1x Alfa 036NHA, 5dbi Stock Antenna, auf dem Balkon 3.OG
RX: 2x TP-Link 722N mit je 1x Alfa 7db Patch Antennen, (in der Hand mit rumgelaufen)
Ergebnis: 450m fliegbar, bis 300m weitestgehend stabiles Signal (immer mal wieder kleinere Glitches, nix Wildes), >300m keine direkte Sichtverbindung mehr (Abschattung durch Baumkronen einer nahegelegenen Allee und Funkschatten durch Hauswände umliegender hoher Gebäude). Signal "kam trodem noch recht gut durch".
Test2: (5,8Ghz)
TX: 1x Alfa 052NH, 2x 5dbi Stock Antennen, auf dem Balkon 3.OG
RX: 2x CSL-300 mit jeweils 1x Stock Antenna (eig. 2,4Ghz) und 1x Alfa 7db Patch Dualband-Antenne,
Ergebnis: bis 300m absolut sauberes Signal, keine Störungen, keine Glitches.... danach machte der Weg eine leichte Biegung und die direkte Sichtverbindung geht verloren (s.o., Abschattung durch Allee und Hauswände) - Resultiert in akutem Verbindungsabriss. Erstaunlich: Verbindung ließ sich teils wiederherstellen indem man andere Hauswände als Reflektionsflächen genutzt hat! Sehr geil!!! - quasi: WiFi-Broastcast-Billard. Das ging sogar hinter(!!!) unserem 4 stöckigen Wohnhaus. Da sieht man mal, wie hohe Frequenzen sich zunhemend wie Licht verhalten. Konnte man eine Reflektionsfläche sehen, dann gabs auch ein sauberes Signal wenn man die Patch-Antennen drauf ausgerichtet hat. Irre!
Bin auf erste Tests auf freiem Feld gespannt.
Good Work!!!
Zuletzt bearbeitet:
rocket:
Okay, d.h. das selbe Fehlerbild bei Euch wenn ich das richtig verstehe:
Heartbeats kommen aus der FC und werden offensichtlich auch richtig übertragen (sonst wären sie nicht mit korrekter CRC in der telemetrylog.raw), werden aber nicht im telemetry.txt log angezeigt. Mavlink GCS Software funktioniert nicht, aber das wifibroadcast OSD funktioniert.
Hmm. Heartbeats nicht im telemetrylog.txt heisst, der Mavlink parser im wifibroadcast OSD kriegt die irgendwie nicht mit. Das wifibroadcast OSD funktioniert trotzdem, weil es sich (ausser sie ins Log zu schreiben) nicht um Heartbeats kümmert.
Cmavnode leitet die Heartbeats anscheinend auch nicht weiter, bzw. erkennt sie nicht. Vielleicht der gleiche Mavlink parser Code da drin? Oder Cmavnode leitet sie weiter, aber der parser code in der GCS Software erkennt die Pakete nicht. Wahrscheinlich, weil die Heartbeats nicht einzeln oder nicht gleichmässig genug ankommen. So zumindest meine Theorie.
Ihr könntet mal probieren andere SR_ Parameter zu setzen (unbenötigtes Zeug deaktivieren, und andere HZ Zahlen), in der Hoffnung, dass dadurch zufälligerweise eine andere Konstellation an Mavlink Messages aus der FC heraus kommt.
Ansonsten mal testweise in der /root/.profile nach diesen beiden Zeilen suchen:
TELEMETRY_BLOCKLENGTH=128
TELEMETRY_MIN_BLOCKLENGTH=20
und auf andere Werte setzen. Einfach blocklength 50, min blocklength 10 oder so. Auch in der Hoffnung, dass dadurch die Messages zufälligerweise irgendwie "richtiger" durchkommen.
der-Frickler:
Es gibt da so eine "gehackte" Firmware bzw. Treiber für die Pi Onboard Wifi Chips: https://github.com/seemoo-lab/nexmon
Habe ich vor ein paar Wochen schonmal probiert, war alles total buggy und nicht zu gebrauchen. Hoffe das wird noch besser, irgendwann werde ich nochmal einen Versuch unternehmen, aber wird dauern.
Careyer:
Ist schön, wenn sich die Theorie auch in der Praxis bestätigt. Habe damit auch schon zuhause herumgespielt und "um die Ecke gefunkt". Bei Omni-Antennen einfach ein Kupferblech im richtigen Winkel schräg dahinter halten und der Empfang ist wieder da
Was sich auch immer wieder bestätigt ist die Sache mit der Reichweite bzw. Link-Budget und Freiraum-Dämpfung. Anzeige war bei 620m bei -82dbm, gibt man die Daten in www.maxmyrange.com ein, kommt 660m heraus. Passt.
Hast Du mal die CTS Protection probiert? Damit sollte das glitchen in der Nähe von Häusern weniger werden.
Alufolie nicht um den Kopf wickeln, sondern grossflächig an strategisch günstig gelegenen Hauswänden in der Umgebung anbringen. Reflektiert noch besser und dämpft auch die WLANs in den Häusern.
stxshadow:
Ja, ist der gleiche Kernel 4.4.11, nur mit den Änderungen wie beschrieben auf Github. Die Sourcen vom 1.5er findest Du auf der Wiki Hauptseite unter den Image downloads.
Okay, d.h. das selbe Fehlerbild bei Euch wenn ich das richtig verstehe:
Heartbeats kommen aus der FC und werden offensichtlich auch richtig übertragen (sonst wären sie nicht mit korrekter CRC in der telemetrylog.raw), werden aber nicht im telemetry.txt log angezeigt. Mavlink GCS Software funktioniert nicht, aber das wifibroadcast OSD funktioniert.
Hmm. Heartbeats nicht im telemetrylog.txt heisst, der Mavlink parser im wifibroadcast OSD kriegt die irgendwie nicht mit. Das wifibroadcast OSD funktioniert trotzdem, weil es sich (ausser sie ins Log zu schreiben) nicht um Heartbeats kümmert.
Cmavnode leitet die Heartbeats anscheinend auch nicht weiter, bzw. erkennt sie nicht. Vielleicht der gleiche Mavlink parser Code da drin? Oder Cmavnode leitet sie weiter, aber der parser code in der GCS Software erkennt die Pakete nicht. Wahrscheinlich, weil die Heartbeats nicht einzeln oder nicht gleichmässig genug ankommen. So zumindest meine Theorie.
Ihr könntet mal probieren andere SR_ Parameter zu setzen (unbenötigtes Zeug deaktivieren, und andere HZ Zahlen), in der Hoffnung, dass dadurch zufälligerweise eine andere Konstellation an Mavlink Messages aus der FC heraus kommt.
Ansonsten mal testweise in der /root/.profile nach diesen beiden Zeilen suchen:
TELEMETRY_BLOCKLENGTH=128
TELEMETRY_MIN_BLOCKLENGTH=20
und auf andere Werte setzen. Einfach blocklength 50, min blocklength 10 oder so. Auch in der Hoffnung, dass dadurch die Messages zufälligerweise irgendwie "richtiger" durchkommen.
der-Frickler:
Es gibt da so eine "gehackte" Firmware bzw. Treiber für die Pi Onboard Wifi Chips: https://github.com/seemoo-lab/nexmon
Habe ich vor ein paar Wochen schonmal probiert, war alles total buggy und nicht zu gebrauchen. Hoffe das wird noch besser, irgendwann werde ich nochmal einen Versuch unternehmen, aber wird dauern.
Careyer:
Ist schön, wenn sich die Theorie auch in der Praxis bestätigt. Habe damit auch schon zuhause herumgespielt und "um die Ecke gefunkt". Bei Omni-Antennen einfach ein Kupferblech im richtigen Winkel schräg dahinter halten und der Empfang ist wieder da
Was sich auch immer wieder bestätigt ist die Sache mit der Reichweite bzw. Link-Budget und Freiraum-Dämpfung. Anzeige war bei 620m bei -82dbm, gibt man die Daten in www.maxmyrange.com ein, kommt 660m heraus. Passt.
Hast Du mal die CTS Protection probiert? Damit sollte das glitchen in der Nähe von Häusern weniger werden.
Alufolie nicht um den Kopf wickeln, sondern grossflächig an strategisch günstig gelegenen Hauswänden in der Umgebung anbringen. Reflektiert noch besser und dämpft auch die WLANs in den Häusern.
stxshadow:
Ja, ist der gleiche Kernel 4.4.11, nur mit den Änderungen wie beschrieben auf Github. Die Sourcen vom 1.5er findest Du auf der Wiki Hauptseite unter den Image downloads.
Ich denke da liegst du richtig, allerdings sehe ich auch in der UDP Rohdaten am Tablet keine Heartbeats. Deswegen wundert mich so dass die Kombi anscheinend bei manchen Usern trotzdem funktioniert. Ich kann bei Gelegenheit den cmavnode Code ansehen, vielleicht ist da heartbeat einfach nicht implementiert, wobei das wär auch komisch.
Careyer:
Ist schön, wenn sich die Theorie auch in der Praxis bestätigt. Habe damit auch schon zuhause herumgespielt und "um die Ecke gefunkt". Bei Omni-Antennen einfach ein Kupferblech im richtigen Winkel schräg dahinter halten und der Empfang ist wieder da
Was sich auch immer wieder bestätigt ist die Sache mit der Reichweite bzw. Link-Budget und Freiraum-Dämpfung. Anzeige war bei 620m bei -82dbm, gibt man die Daten in www.maxmyrange.com ein, kommt 660m heraus. Passt.
Hast Du mal die CTS Protection probiert? Damit sollte das glitchen in der Nähe von Häusern weniger werden.
Alufolie nicht um den Kopf wickeln, sondern grossflächig an strategisch günstig gelegenen Hauswänden in der Umgebung anbringen. Reflektiert noch besser und dämpft auch die WLANs in den Häusern.
Ist schön, wenn sich die Theorie auch in der Praxis bestätigt. Habe damit auch schon zuhause herumgespielt und "um die Ecke gefunkt". Bei Omni-Antennen einfach ein Kupferblech im richtigen Winkel schräg dahinter halten und der Empfang ist wieder da
Was sich auch immer wieder bestätigt ist die Sache mit der Reichweite bzw. Link-Budget und Freiraum-Dämpfung. Anzeige war bei 620m bei -82dbm, gibt man die Daten in www.maxmyrange.com ein, kommt 660m heraus. Passt.
Hast Du mal die CTS Protection probiert? Damit sollte das glitchen in der Nähe von Häusern weniger werden.
Alufolie nicht um den Kopf wickeln, sondern grossflächig an strategisch günstig gelegenen Hauswänden in der Umgebung anbringen. Reflektiert noch besser und dämpft auch die WLANs in den Häusern.
- Status
