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

Status
Nicht offen für weitere Antworten.

rodizio1

Erfahrener Benutzer
Datendurchsatz ist gleich, weil der Pi ja nur einen USB Port hat, egal ob mit oder ohne Hub, es hängt immer alles an dem einem Port. Manche Hubs sollen wohl Probleme machen. Der geht bei mir: https://www.conrad.de/de/4-port-usb-20-hub-schwarz-975100.html Edit: Lässt sich aber schlecht zerlegen (bzw. nur die Platine verwenden), habe es nicht geschafft die alten Kabel abzulöten und neue dranzulöten ohne das sich die Pads gelöst haben ...
 
Zuletzt bearbeitet:

Gravity

Erfahrener Benutzer
Eine Frage zu Verkabelung.
Wie ich vorher erwähnt hab will ich den TX in die Fläche des Opterra bauen.
Wie lang darf den das USB Kabel werden und wie soll ich die „Verkabelung prüfen“ wenn es Augenscheinlich funktioniert? Gibt es Empfehlungen für die Datenleitungen Z.B. twisted pair shielded?
Der Badblock Zäher geht bei mir immer hoch egal ob die Kabel kurz oder lang sind. Getestet an unterschiedlichen Pis und mit jetzt schon 4 verschiedenen WiFi Adaptern und unterschiedlichen Frequenzen. Eine 52er hab ich vermutlich irrtümlich reklamiert. Da gibt’s keine Unterschiede.
Ich hab nur eine Vermutung:
Mein und Nachbars Wifi 2,4 und 5 Ghz. Laut Fritzbox total versucht die Gebend.
Ich kann doch nicht für jeden kleinen Test auf den Acker fahren.
 
Zuletzt bearbeitet:

rodizio1

Erfahrener Benutzer
Steigt das richtig schnell? Gleichmässig? Ein paar lost Packets ab und zu können schon sein, gerade bei nur einer RX Karte (auch durch die periodische VCO calibration beim 052NH), aber das sind dann nach 10min. vielleicht 100 Stück oder so.

Datenleitungen sind bei mir alles ganz normale "Modellbau-Silikonkabel" mit irgendwas um 0.25qmm (was sich halt so findet gerade ...) von Hand verdrillt. Stromleitung mindestens 0.5qmm direkt vom BEC zur Karte, alles direkt verlötet oder mit _vernünftigen_ Steckern (nicht Servostecker etc.) An der Karte auch direkt verlöten, kein USB Stecker.

Im Flügel mit langen Leitungen würde ich einen Low-ESR Elko (10V, irgendwas um 500uF oder so) direkt an der Karte anbringen.
Theoretisch sind geschirmte Kabel natürlich besser, Wenn Du Cat6 Kabel nimmst, könntest Du 6 Adern für Strom und 2 für Daten nehmen.

Störungen lassen sich eigentlich recht einfach ausschliessen: Antennen am RX abschrauben. Achja, und natürlich schauen, dass Du unter -40dbm bist wegen dem Übersteuern. Kannst zur Sicherheit noch über 5700Mhz gehen, da sind keine WLANs (dafür aber vielleicht analoges Zeugs, aber ausserhalb von FPV Plätzen sollte da eigentlich nichts sein). 5580 bis 5560 würde ich auch meiden, es gibt Wetter-Radare mit 1MW Sendeleistung ...
 

Gravity

Erfahrener Benutzer
Hier ein Update von meiner Seite.
Also der TX ist jetzt in der Fläche.
Ich hab eine Mischverkabelung gewählt.
Daten über ein eingelötetes Micro USB Kabel direkt am TX > Pi Zero. Der Stecker wurde noch geschält so dass er durch den Kabelkanal passt. Strom kommt extra über ein 0,5er Kabel-Paar. Die Wärme wird über den nun Alu Deckel abgeführt. Der Fahrtwind sollte den Rest machen. Die Verklebung muss ich nur noch mal überarbeiten, weil Wärme und Klebe verträgt sich nicht.
Empfangstechnisch hat sich nix verschlechtert oder verbessert.
Zu den Auswirklungen auf die RC Telemetrie kann ich jetzt noch nix sagen. Kann aber nur besser werden.




 

herbs

Neuer Benutzer
Gravity, habe weiter getestet, die getrennte Verkabelung hat viel Verbesserung gebracht. Anscheinend hat der UBEC ein zu hoch frequente Brummspannung die sich auf D+ D- überträgt, habe ultra low ESR Elkos bestellt, 470 uF(danke für den Tipp rodizio1), und werde die dann reinschalten und berichten. Lost Packets zur Zeit ca. 30 bei 100k übertragen Paketen nur durch separieren der Spannungsversorgungsleitungen.
 

careyer

DröhnOpaRähta
Cool. Flysky IBUS als Input zur Ground Station oder wird am AirPI das FlySky IBUS Signal generiert?


Gesendet von iPhone mit Tapatalk
 
Zuletzt bearbeitet:

rodizio1

Erfahrener Benutzer
Als R/C Protokoll vom Air Pi zur Flightcontrol. Damit gibt's dann MSP, Mavlink, SUMD und IBUS zur Auswahl an R/C Protokollen, sollte hoffentlich fast alles abdecken an Flightcontrols.
 

Schlonz

Erfahrener Benutzer
Du weisst ja, jetzt schmachten wir alle erst recht auf die 1.6, aber fühle Dich auf gaaaaaar keinen Fall gedrängelt :)
Vielen Dank für die Ganze Arbeit!
Stefan
 

careyer

DröhnOpaRähta
Oje.... jetzt kann ich nicht mehr schlafen... Fast so, also wenn ich noch ein kleiner Bub war und 5 Tage vor Weihnachten schon die Geschenke (leider verpackt) im Keller gefudnen habe :)
 

rodizio1

Erfahrener Benutzer
Wird leider noch etwas dauern, sorry.

Irgendwie ist das Problem mit out-of-order Paketen bei mehreren RX Karten beim telemetry rx wieder aufgetaucht, werde da irgendwie einen Buffer implementieren und die Pakete vorher sortieren müssen, das wird mit meinen bescheidenen C-Kentnissen nicht einfach ...

Ansonsten habe ich noch das Multiplex SRXL R/C Protokoll eingebaut.
 
Wird leider noch etwas dauern, sorry.

Irgendwie ist das Problem mit out-of-order Paketen bei mehreren RX Karten beim telemetry rx wieder aufgetaucht, werde da irgendwie einen Buffer implementieren und die Pakete vorher sortieren müssen, das wird mit meinen bescheidenen C-Kentnissen nicht einfach ...

Ansonsten habe ich noch das Multiplex SRXL R/C Protokoll eingebaut.
Hey!

Die C Kenntnisse sind bei mir auch etwas eingerostet aber wenn Du Unterstützung brauchst gib Bescheid!

LG
 

Schlonz

Erfahrener Benutzer
Wenn Du möchtest, dann packe mal Deine aktuelle Entwicklungsumgebung in ein Image und lege sie mal zum Download hin. Oder ich schicke Dir einen Upload-Link zu unserer Cloud zum Hochladen. Dann kann ich mal mit reinschauen, und auch das Image an Andere wie Rocket weiterverteilen. Vielleicht können wir Dich ein wenig mit unterstützen.

Ist aber nur ein ganz unverbindliches Angebot.

Viele Grüße,
Stefan
 

rodizio1

Erfahrener Benutzer
Hier der letzte Stand:

Anhang anzeigen wb.zip


rx_rc_telemetry.c funktioniert, aber nur mit einer Karte, mit zwei Karten gibt's manchmal out-of-order packets die dann praktisch "verloren" sind.

rx_rc_telemetry_buf.c habe ich gerade mit angefangen, die Idee ist, zuerst Pakete von allen Karten abzuholen (wenn mehr als eins da ist), in ein struct array zu schreiben, dann sortieren und sortiert wieder ausgeben. Läuft aber irgendwie nicht so richtig, ist noch packetloss, weiss gerade nicht wieso, muss noch weiter debuggen.

Was auch noch fehlt ist, noch ein oder zwei Schleifendurchläufe länger zu warten (und weiter frames im buffer struct zu akkumulieren) für den Fall dass die Pakete sozusagen "schleifenübergreifend" out-of-order reinkommen.
 

careyer

DröhnOpaRähta
MEGA! Werde ich heute Abend direkt mal ausprobieren! Hast Du ggf. ein vorläufiges Changelog, sodass wir genauer dort reinschauen können, wo die Änderungen liegen (ich vermute davon gibt es einige). Auf jeden Fall GEIL, dass du mal wieder einen rausgehauen hast. KUDOS!!!!
 
Zuletzt bearbeitet:
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten