FPV Wifi Broadcasting HD Video - Thread zum Raspberry HD Videolink von Befi

Status
Nicht offen für weitere Antworten.
N

nick100

Benutzer
#2.283
#2.283
hab gestern auch gleich zugeschlagen... müsste jetzt alles zusammen haben was die Teile angeht.
Am Wochenende werd ich dann mal basteln. Erstmal kommt die alte Pi Cam dran je nach Bild entweder die neue v2 oder eben dieses CSI HDMI adapter ding obwohl mir die Sache Gimbal und Hdmi Kabel noch Kopfschmerzen bereitet.
Die fertigen Images laufen die auch schon auf dem Zero oder muss ich Raspian erst über einen anderen Pi Updaten ?
 
R

Rangarid

Erfahrener Benutzer
#2.284
#2.284
ap103 hat gesagt.:
Du musst das voltage detection interface belegen, dann kommst du vom cardreader in den live-out mode. Ich hab dazu einfach einen PIN auf 5V gelegt, alternativ den lipo balancer port anschliessen.

Die windows app von biteye hat ca. 220ms latenz, dürfte also nicht wirklich effizient programmiert sein. Falls du das mit der latenz nicht glaubst kannst du
1) selbst den linux code schreiben, die beschreibung des private protocols hast du ja
2) bei gelegenheit meinen code testen damit du selbst messen kannst
btw ich hab den neuen batch der cam.
Zum Vergrößern anklicken....
Also mit der alten FMW war ich bei ca 80ms. Und das war über das Protokoll von Biteye. Lädst du deinen Code mal hoch?
 
T

thomas41587

Erfahrener Benutzer
#2.285
#2.285
Nachdem ich mich so schön gefreut hatte, dass gestern bei einem kurzen Test alles ging, kam heute jetzt leider die Ernüchterung:
Es kommen dauernd Bildfehler. Teilweise "spinnen" einige Pixelblöcke, teilweise ist das gesammte Bild betroffen. Sobald man Bewegung im Bild hat merkt man es richtig stark.

Gibt es hierfür eine Ursache? Ich habe mal Testweise unterschiedliche Kanäle versucht, ohne Erfolg.
Test weise habe ich auch BLOCK_SIZE=8 auf 4 und FECS=4 auf 2 geändert. Ebenfalls keine Besserung...

Die Entfernung bei dem Test waren etwa 2-3m, also nicht wirklich weit
 
R

rodizio

Erfahrener Benutzer
#2.288
#2.288
Hast Du einen Pi1 als Empfänger? Mir ist letztens aufgefallen, dass beim Pi1 als Empfänger bei extrem schnellen Bewegungen der Cam das Bild irgendwie 'kaputt' geht. Wird 'blockig' aber ganz seltsam irgendwie, als ob Teile des Bildes nicht mehr hinterherkommen. Mit dem Pi2 ist das nicht. Hab aber noch nicht weiter geschaut woran es genau liegen könnte. CPU und/oder GPU kommt nicht schnell genug hinterher vielleicht. Oder irgendein Kernel oder Firmware-Bug. Bei mir waren es auf jedenfall keine Funstörungen und auch nicht wegen zu geringer Bitrate. Fällt aber wirklich nur auf, wenn man die Cam wild herumschwenkt.

Würde aber trotzdem erstmal sicherstellen dass es keine Funkstörungen oder Klötzchenbildung wegen zu geringer Bitrate ist.
 
R

rodizio

Erfahrener Benutzer
#2.290
#2.290
Kannst die Bitrate mal auf 7mbit setzen und schauen dass der Codec nicht gezwungen wird die Qualität zu reduzieren durch 'einfache' bzw. gut komprimierbare Szenen, z.b. eine weisse Wand ohne Struktur oder Bilder etc. Wenn der Sender auch ein Pi1 ist kann das aber vom Sender her wieder zu knapp werden von der CPU Leistung mit der hoeheren Bitrate. Mit dem Befehl 'top' kannst Du schauen wie die Last ist, unter 'idle' sollten nie 0 Prozent (=100% ausgelastet) sein, am besten mindestens 10-15%. Übertakten hilft dagegen übrigens.

Schauen ob es Paketverlust bzw. nicht reparierte FEC Blöcke sind kannst du mit dem rx_status_test tool.
 
S

Schalonsus

Erfahrener Benutzer
#2.291
#2.291
thomas41587 hat gesagt.:
Nachdem ich mich so schön gefreut hatte, dass gestern bei einem kurzen Test alles ging, kam heute jetzt leider die Ernüchterung:
Es kommen dauernd Bildfehler. Teilweise "spinnen" einige Pixelblöcke, teilweise ist das gesammte Bild betroffen. Sobald man Bewegung im Bild hat merkt man es richtig stark.

Gibt es hierfür eine Ursache? Ich habe mal Testweise unterschiedliche Kanäle versucht, ohne Erfolg.
Test weise habe ich auch BLOCK_SIZE=8 auf 4 und FECS=4 auf 2 geändert. Ebenfalls keine Besserung...

Die Entfernung bei dem Test waren etwa 2-3m, also nicht wirklich weit
Zum Vergrößern anklicken....
Hier Auszug aus einer Readme von mir, hat schon manchmal geholfen:
Code: 
-Sollten nur Artefakte zu sehen sein und der Stream hängt muss folgendes auf RX Seite gemacht werden:
	mit Username: pi und Password: raspberry anmelden
	sudo nano /boot/config.txt
	dort muss drin stehen (kein # vor den Parametern):
	hdmi_force_hotplug=1
	hdmi_group=2
	hdmi_drive=2
	hdmi_mode=28
	mit STRG+O speichern und STRG+X beenden
	sudo reboot
	jetzt sollte die Verbindung flüssig laufen.
 
R

rodizio

Erfahrener Benutzer
#2.292
#2.292
Ahh, stimmt, das gab bei mir manchmal so grüne Bereiche im Bild, je nachdem wie das Licht war und wohin man die Cam gehalten hat. Passiert wenn man den Monitor erst nach dem Einschalten des Pi anschliesst bzw. einschaltet. Hab nicht geschaut warum, schätze aber mal weil die automatische Erkennung nur beim starten funktioniert und dann ein falscher Mode benutzt wird.

Group 2 Mode 28 wäre DMT 1280x800, nicht für jeden Monitor richtig. Sollte man auf seinen Monitor bzw. Brille anpassen.
 
T

thomas41587

Erfahrener Benutzer
#2.293
#2.293
rodizio hat gesagt.:
Kannst die Bitrate mal auf 7mbit setzen und schauen dass der Codec nicht gezwungen wird die Qualität zu reduzieren durch 'einfache' bzw. gut komprimierbare Szenen, z.b. eine weisse Wand ohne Struktur oder Bilder etc. Wenn der Sender auch ein Pi1 ist kann das aber vom Sender her wieder zu knapp werden von der CPU Leistung mit der hoeheren Bitrate. Mit dem Befehl 'top' kannst Du schauen wie die Last ist, unter 'idle' sollten nie 0 Prozent (=100% ausgelastet) sein, am besten mindestens 10-15%. Übertakten hilft dagegen übrigens.

Schauen ob es Paketverlust bzw. nicht reparierte FEC Blöcke sind kannst du mit dem rx_status_test tool.
Zum Vergrößern anklicken....
Ich habe die Bitrate mal Testweise auf 7mbit gestellt. Für den TX (raspberry B+) scheint es von der Last her kein Problem zu sein (~50%).
Was genau hat eine Änderung der Bitrate zur Folge bzw. was wird besser/schlechter bei einer höheren/niedrigeren Bitrate?

Das rx_status_test tool war ein sehr guter Hinweis, der Damaged Block counter zählt ziemlich schnell nach oben. Hier liegt offenbar das Problem. Der RX ist auch ziemlich an seiner Leistungsgrenze (trotz Übertakten)....

Danke Schalonius für den Hinweis mit den HDMI settings, das hatte ich doch glatt übersehen ;) Allerdings läuft es bei mir übers Handy (Galaxy S4). Also TX pi -> RX pi -> UDP Stream auf Handy

rodizio hat gesagt.:
Group 2 Mode 28 wäre DMT 1280x800, nicht für jeden Monitor richtig. Sollte man auf seinen Monitor bzw. Brille anpassen.
Zum Vergrößern anklicken....
Gibt es eine Auflistung aller Modes? Dann würde ich mal den passenden raussuchen und Testweise am Fernseher anschauen, ob es besser wird...
 
R

Rangarid

Erfahrener Benutzer
#2.294
#2.294
Das hat nichts damit zutun, wenn deine Fehleranzahl sehr hoch ist. Welche Sticks benutzt du? Mit den CSL300 war das bei mir z.B. auch so, kann dir aber nicht genau sagen woran es liegt. Benutzt du Diversity am RX? Dann bräuchtest du einen Raspi2...

Bevor du mit dem Handy testest solltest du erstma mit dem Raspi testen, ob es da flüssig läuft...

Kann unendlich viele Ursachen haben, aber die HDMI Auflösung ist es sicherlich nicht.
 
A

aBUGSworstnightmare

Erfahrener Benutzer
#2.296
#2.296
thomas41587 hat gesagt.:
Gibt es eine Auflistung aller Modes? Dann würde ich mal den passenden raussuchen und Testweise am Fernseher anschauen, ob es besser wird...
Zum Vergrößern anklicken....
Hier findest du eine Auflistung aller Modes https://www.raspberrypi.org/documentation/configuration/config-txt.md

hdmi_group=2 passt, was du jedoch an die Auflösung deines 'HDMI'-Empfängers (Monitor/Brille/..) anpassen musst ist hdmi_mode.
Achtung, nicht verwirren lassen von den; die maximal mögliche Auflösung ist 1900x1200 pixel.
 
Zuletzt bearbeitet:
T

thomas41587

Erfahrener Benutzer
#2.298
#2.298
aBUGSworstnightmare hat gesagt.:
Achtung, nicht verwirren lassen von den 'möglichen' Settings >72; die funktionieren nicht; max. ist 1900x1200 pixel.
Zum Vergrößern anklicken....
Danke für die Auflistung, genau das hatte ich gesucht!

Aber Mode 82 (1920x1080) bzw. 85 (1280x720) sollten funktionieren, obwohl sie >72 sind. Das sind ja die "Standard"-Auflösungen?

Rangarid hat gesagt.:
Dann liegt es vllt einfach daran, dass die Sendeleistung auf so engem Raum zu hoch ist und dadurch Reflektionen oder so auftreten, stell den TX mal in ein anderes Zimmer.
Zum Vergrößern anklicken....
Das wäre natürlich auch denkbar. Werde ich mal ausprobieren. Danke für den Tipp!
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten