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

DerKlotz74 · Jul 3, 2016

So, bin immer noch mit dem runtergetakteten Prozessor und dem 1.2er Image unterwegs.

Jetzt hab ich wieder mehr Pixelbrei. Egal ob 20cm entfernt oder ein Stockwerk tiefer. Spannungsversorgung kann ich ausschliessen. Hab direkt nach dem UBEC und auch direkt auf der Platine des ALFA gemessen. Spannung steht bei 4,99V bis 5,04V.

stxShadow · Jul 3, 2016

Nabend,

ich habe gerade mal folgendes Experiment gemacht: Sender mit Image 1.0 -> Funktioniert einwandfrei.

Empfänger aus einem Pi3 und einem Alpha zusammengesteckt. Bildschirm war meine FPV Brille. Versorgt wurde das ganze von meinem LaborNetzteil.

Leider mit dem 1.2er Image auch hier kein Bild. Ein Problem mit dem Strom kann ich ausschliessen. Das ganze verbraucht nur zwischen 200 und 300 mAH an 5 Volt. Daran kann es nicht liegen. -> siehe Anhang.

Irgendwelche Ideen ?

Danke

Jens

rodizio · Jul 4, 2016

DerKlotz: Hmm, das heisst es geht jetzt immer noch nicht richtig? Mit 5v an der Karte und ohne die zu hohe Sendeleistung wie beim 1.0er Image sollte das jetzt eigentlich sauber klappen. Hab mir jetzt ein paar 5g Antennen bestellt, dann werde ich auch mehr auf 5g testen ...

StxShadow: Echt seltsam. Der alfa leuchtet, Du siehst oben die dbm/Paket anzeige aber kommt trotzdem kein Bild? Wird schwierig jetzt weiter zu schauen. Du könntest mal mit Strg-C abbrechen und 'iwconfig' sowie 'ifconfig' und 'ps ax' eingeben wenn Du noxh Lust hast. Oder warten auf v1.3 (ne Woche noch schätze ich) da wird das leichter einzugrenzen sein weil Infos ausgegeben werden.

careyer · Jul 5, 2016

Servus! Hat sich schon an der Front "Einfrieren" was getan? Hier kam es ja zu der Situation, dass vornehmlich mit dem Rangarid-OSD die GPU irgendwie einfriert und das System bis zum nächsten Neustart komplett blockiert.

Für ein zuverlässiges FPV Fliegen ist das so ja nicht zu gebrauchen bzw. Ein Tanz auf Messers Schneide.

Wäre toll wenn es hier eine Lösung gäbe.

Gesendet von iPhone mit Tapatalk

Rangarid · Jul 5, 2016

Da fällt mir grad was ein, ich hab damals mal was in den Issues der OpenVG Lib gesehen:
https://github.com/ajstarks/openvg/issues/22

Scheint ein ähnliches oder das selbe Problem zu sein. Am Ende wird auf einen Fehler im OpenVG Treiber hingewiesen. Scheint bisher keine Lösung zu geben.

rodizio · Jul 5, 2016

Achtung rant!

Wird irgendwie immer mehr wie Windows 3.1 dieser Linux/Raspi Schrott.

Ahh, also erstmal Stunden an Arbeit investieren, nur damit sich dann hinterher doch keiner drum kümmert weil kein Bock.
VG auf'm Pi praktisch unbenutzbar, kenne ich an so vielen Stellen bei Linux, läuft für kleinscheiss oder nen schnellen Test, aber sobald man irgendwas mal _richtig_ benutzt oder ein wenig buddelt kommt die ganze Frickelei zum Vorschein.

careyer · Jul 5, 2016

Was bedeutet das jetzt für uns? Wir können die die vglib nicht nutzen und den ganzen Telemetrie/OSD Kram in die Tonne treten?

Wenn Displayfehler auftreten dann meistens ausgehend von Buchstaben (haben wir hier auch schon mehrfach gehabt):

Plötzlich auftretende und das Video üebrlagernde Dreiecke (auch schon gehabt... meistes gehen die Dreiecke von einem Buchstaben aus):

Und das Schlimmste: Hin und wieder friert es eben komplett ein!
Während des Fliegens ist das natürlich der SuperGAU.

Habe leider viel zu wenig Ahnung um da so tief einzusteigen... dazu reichen meine Linux-/Programmierkenntnisse einfach nicht aus.
Gibt es eine alternative zur VGlib, sodass man das OSD irgendwie auf eine andere Library portieren könnte?

F***! Wir sind inzwischen so weit gekommen und jetzt verhagelt uns so ein Mist die Show.
GRRRR!!

rodizio · Jul 5, 2016

Das mit den seltsamen Strichen hatte ich auch schon gehabt, OSD und video liefen aber weiter. Weiss leider nicht wie ich das 'detektieren' kann um den osd Prozess neuzustarten.

Das mit dem einfrieren lässt sich durch einen automatischen reboot lösen. Dauert halt dann ca. 10s ...

Ansonsten stand in den Links von Rangarid noch, dass jemand es mit einem bestimmten Kernel stabil hatte, mal schauen ob das eine Möglichkeit ist (und der hoffentlich nicht zu alt ist für Pi Zero firmware). Und irgendeinen Cache flushen hat bei einem noch geholfen, mal schauen ob das was bringt.

Ansonsten bleibt wohl nur, Rangarids OSD nochmal auf eine default Raspbian Installation zu packen, alles an debug logs zu ziehen was geht, das den Entwicklern zur Verfügung zu stellen und hoffen dass die das nachstellen und beheben.

Auf jedenfall sind das erstmal ein paar Ansätze, danke Rangarid.

careyer · Jul 5, 2016

Hi rodizio...

ja, das sind ein paar Ansätze.... irgendwo stand auch mal eine Info, dass man so eine eine Art "Warmstart" der GPU durchführen könne umd das Problem schneller (<<<< 10sec) in den Griff zu bekommen. Dann bräuchte man so eine Art Watchdog, der das Problem erkennt und der GPU daraufhin den Kopf wäscht.

Optimal wäe natürlich die Ursache zu bekämpfen.

Elyot · Jul 5, 2016

Sind die Abstürze denn zufällig oder reproduzierbar? Friert die Anzeige bei mehreren parallelen RX-PIs zum gleichen Zeitpunkt ein?

rodizio · Jul 5, 2016

Elyot:
Ziemlich zufällig aber reproduzierbar. Manchmal dauert's ne halbe Stunde bis es abstürzt, manchmal läuft's 3 Tage am Stück durch, aber irgendwann passiert es.

Liegt am RX, wenn das passiert und ich dann einen weiteren Pi als RX starte läuft alles sofort ohne den TX anzufassen.

Careyer:
Ja, das mit dem GPU Reset hatte ich gepostet, mir fehlt leider nur das Programmier-Wissen um daraus was zu machen. Wenn jemand ein kleines Tool baut was den GPU Reset durchführt, könnte man das automatisch machen sobald die GPU hängt. Dann würde die Unterbrechung wahrscheinlich max. eine Sekunde oder so dauern.

Elyot · Jul 5, 2016

Ich meinte eher, wenn 2 PIs das selbe Signal empfangen, frieren dann auch beide gleichzeitig ein? Oder läuft einer munter weiter, bis er zu einem späteren Zeitpunkt kalte Füße bekommt?

rodizio · Jul 5, 2016

Das hab ich so nicht getestet. Ich schätze mal, der zweite friert dann halt irgendwann zu einem anderen Zeitpunkt ein.

careyer · Jul 5, 2016

Ja, ich denke der TX ist da völlig raus.... irgendwas läuft da im RX schief (Speicherfehler oder dergelichen). Das blöde ist in der Tat, dass es mit an Sicherheit grenzender Wahrscheinlichkeit IMMER(!) auftritt....

Mal nach 30min, mal nach 5min.... mal nach 3 Tagen. Man könnte auch sagen: Völlig unberechenbar.
Weiterns konnten wir das Fehlverhalten durch unzählige versuche insoweit präzisieren, als dass die Wahrscheinlichkeit zunimmt je mehr man den OSD Prozess rendern lässt. Also je mehr Sachen und je aufwändigere Sachen man anzeigt desto eher die Wahrscheinlichkeit, dass sich die GPU in den Kopf schießt.

Pakete kommen dann über die WLAN Schnittstelle weiter rein... aber sowohl der Video- als auch der OSD Prozess hängen sich beide auf und lassen sich auch nicht mehr killen (glaube das nennt man Zombie-Prozess, oder?). Da hilft (aktuell) nur ein Neustart -- leider ein NoGo! während des Flugs.... (egal wie schnell das Image startet)....

Ein paar verlorene Frames wären akzeptabel... aber bis zu 10sec Bildausfall ist schlecht. Zumindest wenn man keinen sehr eigenstabilen Kopter und in jede Richtung 100m freien Luftraum hat. ;-)

Da müssen wir irgendwie ran.
Gibt es jemanden der rodizio helfen könnte? Ich bin wie gesagt leider kein Programmierer aber ich helfe gerne bei den zahlreichen (und leider langwierigen Tests)

LG
Thomas

Rangarid · Jul 5, 2016

Irgendwer muss halt ein OpenGL OSD schreiben. Wurde ja auch schon für die Android App gemacht mein ich.

rodizio · Jul 5, 2016

Hmm, im Moment bin ich eher dafür rauszufinden warum das nicht klappt bzw. das irgendwie besser reproduzierbar zu machen damit das Problem an der Wurzel (Vglib oder wahrscheinlicher Raspi) gefixt werden kann. Wenn natürlich jemand ein OpenGL osd macht, dann bau ich das auch gerne ein

Das OSD ist doch ansonsten gut. Oder würde OpenGL sonst noch Vorteile bringen (Weniger CPU Last z.B.)?

Könntest Du vielleicht ohne viel Aufwand was bauen, was 'wie wild rummalt', um das auftreten des Problems zu beschleunigen Rangarid?

Rangarid · Jul 5, 2016

Ich denke OpenGL ist nochmal etwas schneller. Was mir aufgefallen ist, ist dass openVG in der Implementierung wie sie in der AJStark lib vorliegt extrem langsam ist, wenn man komplexe Formen zeichnet. Hier ist ein schönes OpenGL Tutorial für Raspi:
https://jan.newmarch.name/LinuxSound/Diversions/RaspberryPiOpenGL/

Ich teste das nachher mal kurz an, ob das über dem Video läuft ohne viel Aufwand, dann kann ich vielleicht einfach die Methoden für Line, Rectangle usw. in OpenGL umschreiben, die ich in meinem OSD nutze, dann wär es nicht soviel Aufwand das anzupassen.

careyer · Jul 5, 2016

Daumen hoch Rangarid!

Gesendet von iPhone mit Tapatalk

DerKlotz74 · Jul 7, 2016

rodizio hat gesagt.:

Sorry,
bin die letzten Tage zu nichts gekommen. Wollte nur sagen, dass ich immer noch nicht weiter bin. Ich kann nur 2,4GHz und 2,4/5GHz Hardware zum Testen "zur Verfügung" stellen.
Fakt ist, dass aktuell mein ALFA AWUS051NH und AWUS036NHA egal ob Tx oder Rx, mir die Suppe versalzen.

Ich werde bald alle Kombinationen der Hardware laufen lassen und berichten, was dabei rauskommt.

Vielen Dank an alle Helfer

Louger · Jul 8, 2016

Ich plane aktuell mir einen Odroid-W zuzulegen um direkt auf mein Tablet/Convertible zu streamen (Asus T100ta).

Ich bin nun unsicher, ob ich nun lieber die Raspberry Cam 1.3 oder 2.8 kaufen soll. Lohnt der Aufpreis der neueren (Links siehe unten)?
Wie verhält sich das mit den Linsen, kann ich jederzeit auf die Module eine Linse aufstecken, oder brauche ich da ein spezielles Modul?
Ich hätte gerne zwischen 130 und 140° Sichtfeld.

Zudem bin ich durch die Berichte der letzten Seiten hier im Thread etwas unsicher, welche WLan-Sticks ich kaufen sollte. Ich möchte auf 5,8GHz übertragen, da ich bereits eine Taranis nutze.
Die Alfa scheinen laut einigen hier Probleme zu machen. Die CSL300 werden bereits am Anfang als "schlecht" abgetan...
Zu Welchen Sticks würdet ihr mir raten?

Liebe Grüße
Roland

http://www.pollin.de/shop/dt/Njk5Nj...berry_Pi/Raspberry_Pi_Kameramodul_V2_8MP.html

http://www.ebay.de/itm/Camera-Modul...008466?hash=item4af8846e52:g:3jsAAOSwbYZXV9Zi

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

Erfahrener Benutzer

Erfahrener Benutzer

Anhänge

Erfahrener Benutzer

DröhnOpaRähta

Erfahrener Benutzer

Erfahrener Benutzer

DröhnOpaRähta

Erfahrener Benutzer

DröhnOpaRähta

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

DröhnOpaRähta

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

DröhnOpaRähta

Erfahrener Benutzer

Neuer Benutzer