Vielleicht hilft das hier beim zusammenlöten: http://www.ebay.de/itm/112108027663
EZ-Wifibroadcast, HD FPV in günstig und einfach
- Themenstarter rodizio
- Beginndatum
- Status
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.
Das müsste ich ausprobieren. Gab es da grundlegende Änderungen?
Lade die Imagedatei gerade herunter.
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
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
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.
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?
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?
Hmm, seltsam. Muss nochmal nachschauen was ich alles geändert hab
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.
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
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.
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.
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.
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.
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.
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
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:
Hätte mal eine (vielleicht dumme ) 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?
) 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?
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:
Danke und Gruss
Jens
Gesendet von meinem SM-G928F mit Tapatalk
Danke und Gruss
Jens
Gesendet von meinem SM-G928F mit Tapatalk
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.
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.
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.
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.
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
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
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.
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
