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

Status
Nicht offen für weitere Antworten.
Der Zero als RX ist definitiv zu schwach.

Ansonsten ist mein Test-Setup (RX und TX je mit Modem) bei 1.7A an 5.1V an einem Labornetzteil.

Strom also genügend. Ev Spannung nachmessen?

Ich hatte ähnliche Probleme. Was bei mir half: schlechtere Antennen(!!!) und mehr Abstand dazwischen.

Ich habe den A+ als TX und den Pi2 als RX im Einsatz. Der Zero würde wenn dann nur als TX eingesetzt werden.
Habe den Problem-Pi :)p) ans Labornetzteil angeschlossen. Wenn ich die Spannung auf exakt 5.0V einstellen, bekomme ich das Blitzsymbol angezigt. Erst ab einer eingestellten Spannung von 5.1V verschwindet es.
Das Problem bleibt allerdings trotzdem bestehen.


Transporter:
Ich bin eigentlich immer davon ausgegangen, dass die A-Modelle "gleich genug" sind und auch laufen sollten (soweit ich weiss benutzen den auch Leute mit EZ-Wifibroadcast). Mittlerweile habe ich aber viel im Raspberry Forum gelesen, die Dinger haben je nach Revision verschiedene USB- und Stromversorgungsprobleme, könnte sein dass es daran liegt. Da ich selbst keine A+ Modelle habe und daher nicht damit testen kann, sind die A-Modelle ab 1.4 offiziell nicht mehr unterstützt, sorry.

Läuft es denn mit EZ-Wifibroadcast 1.2?
Das müsste ich ausprobieren. Gab es da grundlegende Änderungen?
Lade die Imagedatei gerade herunter.


Wenn Du das Problem weiter einkreisen willst:

- Das Blitz-Symbol erscheint, wenn der Pi unter 4.65V sieht. Das BEC ist direkt an den GPIO Pins? Würde da mal die Spannung messen während der TX sendet.
- Was heisst "Stromversorgung vom 052NH direkt am Pi angelötet"? Die sollte direkt zum BEC gehen, nicht über die Pi USB-Ports. Messe auch mal die Spannung direkt am 052NH während er sendet.
- Setze mal testweise overclocking ein wenig herunter in der config.txt: arm_freq=900 und gpu_freq=300
- Reduziere die Sendeleistung des 052NH: Einloggen, dann "rw", dann "nano /etc/modprobe.d/rt2800usb.conf" darin dann txpower=-5 setzen und mit CTRL-X und "Y" beenden und speichern

Spannungstoleranz ist offiziell 4.8-5.2V (direkt an den GPIO Pins gemessen), am sichersten ist aber wirklich über 5.00V zu bleiben (4.95 ist wohl auch noch okay). Das offizielle Pi Netzteil z.B. hat 5.2V.
Das BEC geht direkt auf die GPIO Pins. Das BEC ist auf die Pins gesteckt, die Stromversorgung des 052H habe ich unten an die Pins gelötet, sieht geht nicht über den USB-Port oder dessen Stromanschlüsse.

Habe den Pi nun an ein Labornetzteil angeschlossen. Ab 5,1V verschwindet das Blitz Symbol. Das Problem bleibt allerdings weiterhin.
Das Bild ist nicht komplett voll mit Artefakten, es ist immer nur der obere Bereich. Die restlichen 4/5 sind wie auf dem Bild von meinem letzten Beitrag, allerdings nicht permanent, sondern flackernd. Für ganz kurze Zeit ist das Bild manchmal ohne Artefakte.

Die Zahlen oben links im Bild geben vermutlich die Anzahl der korrekt empfangen und defekten Datenpakete an?
Ich habe nach weniger als einer Minute über 300 verloren gegangene Pakete.

Die Videobitrate habe ich Testweise auch schon von 6 auf 2Mbit reduziert, aber ohne Besserung, ist exakt gleich wie vorher.


Nique:


Ob es die Geschichte mit dem "Übersteuern" ist, lässt sich leicht testen:

- Tritt nur mit Ralink Karten als RX auf
- Fängt ab Signalstärken von ca. -30dbm und stärker an

Wenn Ihr als soviel Abstand zwischen RX und TX bringt dass das Signal sagen wir mal -40dbm ist, sollte es auf jedenfall stabil sein.

Mache gerade einen Langzeit-Test, bis jetzt:
up 3 days, 18:24, 0 users, load average: 0.27, 0.23, 0.25
RX bytes:264437285012 (246.2 GiB)


ca. 247 Millionen Pakete übertragen.

Während dieser 3 Tage und 18 Stunden 4 Badblocks. Also grob 1 Badblock pro Tag :)
Das habe ich auch schon getestet. Die Artefakte gehen auch nicht weg wenn ich TX und RX weiter voneinander entferne.
Habe es bis -74dbm getestet. Aber die Artefakte sind immer exakt gleich von der Art her. Es wird nicht besser aber auch nicht schlechter.

Vielen Dank schon mal für die Anregungen. Werde jetzt mal V1.2 testen.
 
Transporter:

Läuft es denn mit EZ-Wifibroadcast 1.2?
Gleicher Versuchsaufbau wie vorher (Labornetzteil anstatt BEC), nur mit V1.2 anstatt 1.4 und es scheint zu funktionieren!
Ich habe bei 3000 Paketen 8 schlechte dabei bei einem Abstand von ca. 1m zwischen TX und RX.

Der Stromverbrauch mit 1.2 ist höher als mit 1.4: 1,05A vs 0,9A.
Mit 1.4 habe ich gefühlt (kann es durch die Dauer-Artefakte nicht genau sagen) einen deutlich besseren Empfang bei einem Reichweitentest in der Wohnung.

Woran kann das liegen dass es mit 1.2 funktioniert? Kann ich 1.4 mit den neuen Funktionen verwenden, die Einstellungen aber so ändern dass der Empfang wie bei 1.2 ist?

Wenn ich mir einen Pi2 oder Pi3 als TX kaufen würde, würde das das Problem lösen?
 

rodizio1

Erfahrener Benutzer
Hmm, seltsam. Muss nochmal nachschauen was ich alles geändert hab :D

Verdrahtung klingt soweit richtig.

Höherer Stromverbrauch ist weil ich ab 1.4 die overvoltage einstellung reduziert habe. Probier das vielleicht mal in der config.txt zu ändern. Also in der v1.4 in der config.txt overvoltage von "4" auf "6" stellen. Aber eigentlich sollten dadurch nicht solche badblocks in Mengen kommen.

Der bessere Empfang bei 1.4 kommt durch die niedrigere Wifi Bitrate (ergibt eine höhere Empfindlichkeit) und Verbesserungen beim Diversity.

Hast Du v1.2 jetzt auf Rx UND Tx gemacht? Probier bitte mal 1.2 auf Rx und 1.4 auf Tx (und auch anders herum) um zu sehen ob es am Rx oder Tx liegt.
 
Zuletzt bearbeitet:
Hmm, seltsam. Muss nochmal nachschauen was ich alles geändert hab :D

Verdrahtung klingt soweit richtig.

Höherer Stromverbrauch ist weil ich ab 1.4 die overvoltage einstellung reduziert habe. Probier das vielleicht mal in der config.txt zu ändern. Also in der v1.4 in der config.txt overvoltage von "4" auf "6" stellen. Aber eigentlich sollten dadurch nicht solche badblocks in Mengen kommen.

Der bessere Empfang bei 1.4 kommt durch die niedrigere Wifi Bitrate (ergibt eine höhere Empfindlichkeit) und Verbesserungen beim Diversity.

Hast Du v1.2 jetzt auf Rx UND Tx gemacht? Probier bitte mal 1.2 auf Rx und 1.4 auf Tx (und auch anders herum) um zu sehen ob es am Rx oder Tx liegt.
1.2 war auf TX und RX

Neuer Test:

TX: 1.4 ; RX: 1.2
=> Keine Verbindung mit Standardeinstellungen

TX: 1.2 ; RX 1.4
=> Keine Verbindung mit Standardeinstellungen

Könnte es sein dass die CSL300 als 2,4GHz Chipsätze erkannt werden und der 052 als 5,8GHz Chipsatz?
Da war glaube ich in den vorherigen Versionen eine Unterscheidung in einer txt-Datei.

Beide wieder auf 1.4: Habe beim TX die in der config overvoltage von 4 auf 6 geändert, hat aber leider auch nichts gebracht.

Werde mich morgen nochmal damit auseinander setzten.
 

rodizio1

Erfahrener Benutzer
Hast Du die Frequenzen überall gleich?

1.2 hat als Standard 2484Mhz, 1.4 hat 2472Mhz. Zwischen den Chipsätzen bzw. Bändern wird nicht unterschieden, sollte also immer auf 2.4 laufen mit default settings.

Stell auf jedenfall wieder auf 5G mit allen Versionen, auf 2.4G zieht die Karte weniger Strom, kann auch sein, dass es deshalb lief mit V1.2.
 

stxShadow

Erfahrener Benutzer
Hast Du die Frequenzen überall gleich?

1.2 hat als Standard 2484Mhz, 1.4 hat 2472Mhz. Zwischen den Chipsätzen bzw. Bändern wird nicht unterschieden, sollte also immer auf 2.4 laufen mit default settings.

Stell auf jedenfall wieder auf 5G mit allen Versionen, auf 2.4G zieht die Karte weniger Strom, kann auch sein, dass es deshalb lief mit V1.2.
Und denk an die unterschiedliche WiFi bitrate....

Gesendet von meinem SM-G928F mit Tapatalk
 

DangerDave

Erfahrener Benutzer
Hallo,
wollte nur kurz Rückmeldung geben, bei mir klappt die Telemetrie jetzt auch mit dem Level-Konverter! Dass ich vorher mit 5V Signal auf den GPIO Pins des Pis war, scheint bei mir keinen Schaden hinterlassen zu haben.

Besten Dank euch, Feldtests werden folgen bei besserem Wetter!
 
TX: 1.2 , RX: 1.4
mit angepasstem Kanal und Wifi Bitrate auf 18 MBit/s
Verbindung, aber weiterhin selbes Problem mit Artefakten wie bisher

TX: 1.4, RX: 1.2
mit angepasstem Kanal und Wifi Bitrate auf 18 MBit/s (einfach die SD Karten getauscht)
Verbindung ohne permanente Artefakte, jedoch mehr Badblocks als mit 1.2 auf beiden Seiten:
73/3000

Mit 1.2 auf beiden Seiten:
8/3000

Edit:
WLAN Frequenz im Haus kann auch ausgeschlossen werden. Gesendet wird auf Kanal 1 und 8, Wifibroadcast sendet auf Kanal 13.

Edit2:
Bisher bestes Ergebnis:
TX: 1.4, RX: 1.2
OSD deaktiviert
3/4000 Badblocks (Badblockanzeige funktioniert trotz deaktiviertem OSD


Nach Kartentausch:

TX: 1.2, RX: 1.4
OSD deaktiviert
Weiterhin die gleichen Probleme mit Artefakten; Badblocks nicht ablesbar, da OSD deaktiviert

Es scheint also definitiv am RX zu liegen, in Kombination mit V1.4
RX: Pi2 mit 2x CSL300

Der RX hängt sich mit 1.2 auf bei schlechtem Empfang und kommt auch nicht mehr zurück
 
Zuletzt bearbeitet:

rodizio1

Erfahrener Benutzer
Das ist seltsam. Also Pi2 in Verbindung mit 1.4. Werde das nochmal durchtesten ...

Das mit dem hängen bei vielen badblocks bei 1.2 ist seit 1.3beta behoben.

War das jetzt alles auf 2.4G? Wolltest Du nicht 5G nehmen?
 
Hätte mal eine (vielleicht dumme :D) Frage:
Und zwar, ob das Image auch auf einem ganz normalen Rechner/Laptop oder einer Virtuellen Maschine läuft?, oder ist es dafür zu sehr auf den Raspi zugeschnitten?
 

stxShadow

Erfahrener Benutzer
Hmmmm... Eine Frage habe ich dann auch noch: was muss ich tun um z.b. die Höhe und die Geschwindigkeit zu sehen ? Natürlich habe ich diese im osd config file aktiviert. Funktioniert aber leider nicht. Andere Element werden sauber angezeigt. Gibt es ggf unterschiedliche Mavlink Protokolle? Werden die Ladders immer angezeigt, auch wenn keine sauberen Werte da sind ? Bei mir sieht es mit so ziemlich allen Optionen aktiviert so aus:

20170118_233959.jpg

Danke und Gruss

Jens

Gesendet von meinem SM-G928F mit Tapatalk
 

rodizio1

Erfahrener Benutzer
Transporter: Habe nochmal mit einem Pi2 mit CSL300 und 052NHA als RX getestet (für 2x CSL300 hätte ich jetzt alles umlöten müssen ...). Funktioniert einwandfrei, 0 badblocks auf 5.8Ghz. 2.4Ghz gibt natürlich immer mal wieder ein paar badblocks durch die ganzen WLANs hier, aber es 'rattert' nicht wie bei Dir.

Probier' vielleicht mal nur einen CSL300 als RX am Pi2.

stxShadow:

Eigentlich sollten da ladders bzw. auch Höhenangaben in Zahlenform sein. Das OSD unterstützt folgende Mavlink Messages:
https://github.com/bortek/EZ-WifiBroadcast/wiki/OSD-MAVLink-message-types

Was noch auffällt: Du hast fast 3x soviele OSD Blocks übertragen wie Videoblocks. Könnte die Videoübertragung beeinflussen. Da scheinen jede Menge Daten aus der FC zu kommen, am besten ist es das so zu reduzieren, dass nur das nötigste kommt. Teste vielleicht auch mal eine grössere OSD_BLOCKLENGTH um das zu reduzieren, 128 oder 256.
 

stxShadow

Erfahrener Benutzer
stxShadow:

Eigentlich sollten da ladders bzw. auch Höhenangaben in Zahlenform sein. Das OSD unterstützt folgende Mavlink Messages:
https://github.com/bortek/EZ-WifiBroadcast/wiki/OSD-MAVLink-message-types

Was noch auffällt: Du hast fast 3x soviele OSD Blocks übertragen wie Videoblocks. Könnte die Videoübertragung beeinflussen. Da scheinen jede Menge Daten aus der FC zu kommen, am besten ist es das so zu reduzieren, dass nur das nötigste kommt. Teste vielleicht auch mal eine grössere OSD_BLOCKLENGTH um das zu reduzieren, 128 oder 256.
Die Blocks sind nicht das Problem. Ich habe nur etwas mit restarts etc rumgespielt. Diese sind so schon in Ordnung. Sie reduzieren sich z.b. bei einer anderen OSD_Baudrate massive. -> wie gesagt ... das ist hier nicht das Problem.

Der APM steht auf Mavlink1, ich werde heute Abend mal die messages auseinandernehmen um zu gucken, ob da auch wirklich alles ankommt bzw ausgegeben wird, was das OSD verarbeiten kann.

Gruß

Jens

PS: das mit dem Level Converter funktioniert bei mir zwischen einem APM und dem Raspberry Zero überhaupt nicht. Ich habe die Pegel mit meinem Oszilloskop gemessen und komme da auch kaum 2 Volt Spitze Spitze ..... entweder ich mache da was falsch oder die Pegelwandler arbeiten auch nicht alle sauber.
 

stxShadow

Erfahrener Benutzer
Die Blocks sind nicht das Problem. Ich habe nur etwas mit restarts etc rumgespielt. Diese sind so schon in Ordnung. Sie reduzieren sich z.b. bei einer anderen OSD_Baudrate massive. -> wie gesagt ... das ist hier nicht das Problem.

Der APM steht auf Mavlink1, ich werde heute Abend mal die messages auseinandernehmen um zu gucken, ob da auch wirklich alles ankommt bzw ausgegeben wird, was das OSD verarbeiten kann.

Gruß
Antwort auf meine eigene Frage: es gibt nicht alle messages bei APM. Was ich im Source nicht finden konnte waren:

latitude = mavlink_msg_global_position_int_get_lat
longitude = mavlink_msg_global_position_int_get_lon

diese beiden heissen:

m2h_gps_lon = mavlink_msg_gps_raw_int_get_lon(&msg); // latitude 2
m2h_gps_lat = mavlink_msg_gps_raw_int_get_lat(&msg); // longitude 3

heading = mavlink_msg_global_position_int_get_hdg

müsste sein:

m2h_heading = mavlink_msg_vfr_hud_get_heading(&msg);

Ich werde darum heute Abend mal Mavlink2 ausprobieren. Vielleicht sind die Messages da ja definiert.

Gruß

Jens
 

rodizio1

Erfahrener Benutzer
Habe mal nach den beiden messages hier gesucht, und bin in Rangarid's open360tracker fündig geworden :)

m2h_gps_lon = mavlink_msg_gps_raw_int_get_lon(&msg); // latitude 2
m2h_gps_lat = mavlink_msg_gps_raw_int_get_lat(&msg); // longitude 3

https://github.com/SamuelBrucksch/open360tracker/blob/master/open360tracker/mavlink.cpp
(in der mavlink_handleMessage Funktion)

Die scheinen wohl genau die gleichen Daten zu liefern. Theoretisch liessen die sich also zum OSD code zufügen.
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten