EZ-Wifibroadcast, HD FPV in günstig und einfach
- Themenstarter rodizio
- Beginndatum
- Status
@Louger
auf die standartcams kannst du keine linse wechseln oder draufschrauben. für die erste version der cam gibts aber spezielle versionen von drittanbietern mit unseren bekannten linsen.
an alle:
wie muss der usb-stick formatiert werden damit die aufnahme klappt?
ich hab auf die schnelle ein noname stick angeschlossen und es hat mit fat32 und ntfs nicht geklappt.
ich fliege auf 5,8ghz und hab mangels adapter mit stabantennen nur 100m geschafft bei 96ms latenz und standarteinstellungen. man merkt es, aber für den trägen hex ist es nicht so schlimm. racen kann man damit aber nich.
TX: PiZero, CSL300, noch stabantennen, kein powermod, 5V über Adapter Input PIN (GPIO)
RX: PI2B, 2x AWUS051NH v2, noch stabantennen, StromPi, kein USB-Hub, kein powermod
Monitor: HeadplayHD
auf die standartcams kannst du keine linse wechseln oder draufschrauben. für die erste version der cam gibts aber spezielle versionen von drittanbietern mit unseren bekannten linsen.
an alle:
wie muss der usb-stick formatiert werden damit die aufnahme klappt?
ich hab auf die schnelle ein noname stick angeschlossen und es hat mit fat32 und ntfs nicht geklappt.
ich fliege auf 5,8ghz und hab mangels adapter mit stabantennen nur 100m geschafft bei 96ms latenz und standarteinstellungen. man merkt es, aber für den trägen hex ist es nicht so schlimm. racen kann man damit aber nich.
TX: PiZero, CSL300, noch stabantennen, kein powermod, 5V über Adapter Input PIN (GPIO)
RX: PI2B, 2x AWUS051NH v2, noch stabantennen, StromPi, kein USB-Hub, kein powermod
Monitor: HeadplayHD
Zuletzt bearbeitet:
Hmmm ........ ich hatte heute endlich etwas Zeit zum debuggen .... und was soll ich sagen: es war ein Layer8 Problem. Das ganze funktioniert bei mir nun auch mit der 1.2er Version. Das eigentliche Problem war, dass ich die SD Karten im Linux per DD überschrieben habe. Diese werden jedoch beim einstecken ersteinmal automatisch gemountet. Hierdurch "lernt" der Kernel die Partitionstabelle. Wenn ich nun "unmounte" und einfach perr dd überschreibe passiert hier dann beim überschreiben Blödsinn und das neu geschriebene Image funktioniert nicht. Lösung war: SD Karte von Hand unmounten, Partitionen mit gparted löschen, rebooten und dann neu schreiben. Durch das Rebooten (ich weiss ... ein rescan geht auch ... aber sicher ist sicher), wird dann die alte Tabelle weggeworfen .... und die leere Karte sauber erkannt, welche ich denn per dd überschreiben konnte.
Ich habe dann noch die Sendeleistung der Alphas zwischen den Images verglichen. Bilder Dazu im Anhang. Bild 1 -> altest Image 1.0 ... Bild2 -> neues Image 1.2. Fazit: Ich komme hier auf einen Unterschied auf Empfängerseite von etwa 3-4 DBm.
-30 DBm zu -33 DBm entspricht laut dieser Tabelle http://www.dl2lto.de/sc/TM_tab_pegel.htm so ziemlich genau der Hälfte der Empfangsstärke. Praxistests stehen aber noch aus. Ich werde entsprechende Bodenaufnahmen nachliefern.
Viele Grüße
Jens
PS: einen hätte ich noch: da ich nun viel mit den verschiedenen Versionen gespielt habe hätte ich gerne beim bootsplash (ich nehme an der wird genutzt) die Version hinter dem wifibroadcast .... sollte einfach zu realisieren sein oder ?
Ich habe dann noch die Sendeleistung der Alphas zwischen den Images verglichen. Bilder Dazu im Anhang. Bild 1 -> altest Image 1.0 ... Bild2 -> neues Image 1.2. Fazit: Ich komme hier auf einen Unterschied auf Empfängerseite von etwa 3-4 DBm.
-30 DBm zu -33 DBm entspricht laut dieser Tabelle http://www.dl2lto.de/sc/TM_tab_pegel.htm so ziemlich genau der Hälfte der Empfangsstärke. Praxistests stehen aber noch aus. Ich werde entsprechende Bodenaufnahmen nachliefern.
Viele Grüße
Jens
PS: einen hätte ich noch: da ich nun viel mit den verschiedenen Versionen gespielt habe hätte ich gerne beim bootsplash (ich nehme an der wird genutzt) die Version hinter dem wifibroadcast .... sollte einfach zu realisieren sein oder ?
Anhänge
Zuletzt bearbeitet:
Wen auch das "Operation Failed" im 1.2er Image nervt -> es gibt einen sehr einfachen Weg das loszuwerden.
Einfach stderr und stdout ins Datennirvana schicken. Die entsprechende Zeile findet Ihr in /home/pi/.profile !!
Hier sucht Ihr die Zeile 43 und ändert sie folgendermassen ab:
sudo pump -h wifibrdcast-rx > /dev/null 2>&1 &
Danach ist die lästige Zeile verschwunden.
Einfach stderr und stdout ins Datennirvana schicken. Die entsprechende Zeile findet Ihr in /home/pi/.profile !!
Hier sucht Ihr die Zeile 43 und ändert sie folgendermassen ab:
sudo pump -h wifibrdcast-rx > /dev/null 2>&1 &
Danach ist die lästige Zeile verschwunden.
@bandtaucher: wie Du an meinen Screenshots sehen kannst, ist das Operation Failed teilweise sehr wohl zu sehen.
Die Zeile bewirkt eigentlich nur, dass ein DHCP Client Prozess für das Netzwerk gestartet wird. Jeder, der ein Netzwerkkabel angeschlossen hat, sowie einer DHCP Server (Router, Handy usw) im Netzwerk zur Verfügung hat, wird dieses Operation Failed nicht sehen. Ich finde es aber einfach lästig. Das 2>&1 bewirkt nur, daß sämtliche Ausgaben des pump Prozesses ins Nirvana gehen und nicht fälschlicherweise angezeigt werden und das Hello_Video beeinträchtigen. Ansonsten ist die Funktion in keiner Weise verändert. Da hier schon viele Fragen zu "Operation failed" aufkamen, kann man diesen "Fehler" so auf einfache Weise verhindern.
Gruß
Jens
Die Zeile bewirkt eigentlich nur, dass ein DHCP Client Prozess für das Netzwerk gestartet wird. Jeder, der ein Netzwerkkabel angeschlossen hat, sowie einer DHCP Server (Router, Handy usw) im Netzwerk zur Verfügung hat, wird dieses Operation Failed nicht sehen. Ich finde es aber einfach lästig. Das 2>&1 bewirkt nur, daß sämtliche Ausgaben des pump Prozesses ins Nirvana gehen und nicht fälschlicherweise angezeigt werden und das Hello_Video beeinträchtigen. Ansonsten ist die Funktion in keiner Weise verändert. Da hier schon viele Fragen zu "Operation failed" aufkamen, kann man diesen "Fehler" so auf einfache Weise verhindern.
Gruß
Jens
Ja, diese nervigen automounter, hatte ich auch schon so seltsame Effekte mit.
Beim alten Image war der Register-Wert für die Sendeleistung auf 63 (maximalwert) gesetzt, im 1.2er auf 60. Lt. den Entwicklern sind das 0.5db Schritte, sollte also theoretisch 1.5db weniger sein. Ich hatte bei meinen Tests 2db gesehen (ist eh nicht auf ein dB genau ...). Werde das aber sowieso noch einstellbar machen ...
Ja, gute Idee. Das grüne "Wifibroadcast" ist einfach nur das Tux Logo im Kernel durch ein anderes ersetzt.
Beim alten Image war der Register-Wert für die Sendeleistung auf 63 (maximalwert) gesetzt, im 1.2er auf 60. Lt. den Entwicklern sind das 0.5db Schritte, sollte also theoretisch 1.5db weniger sein. Ich hatte bei meinen Tests 2db gesehen (ist eh nicht auf ein dB genau ...). Werde das aber sowieso noch einstellbar machen ...
Ja, gute Idee. Das grüne "Wifibroadcast" ist einfach nur das Tux Logo im Kernel durch ein anderes ersetzt.
Jop.
Irgendwie ist das seltsam mit den 802.11n Datenraten, nur 2 Mbit mehr, aber dafür 1dB weniger Sendeleistung und 7dB weniger Empfindlichkeit, zumindest lt. Datenblatt lohnt das doch garnicht (?) bzw. ich frage mich, wozu es diese Modes überhaupt gibt. (hier vom RT5572 http://www.unex.com.tw/wi-fi/dnur-s2)
Wollte irgendwann nochmal gegentesten ob das in der Praxis auch soviel schlechter aussieht.
Irgendwie ist das seltsam mit den 802.11n Datenraten, nur 2 Mbit mehr, aber dafür 1dB weniger Sendeleistung und 7dB weniger Empfindlichkeit, zumindest lt. Datenblatt lohnt das doch garnicht (?) bzw. ich frage mich, wozu es diese Modes überhaupt gibt. (hier vom RT5572 http://www.unex.com.tw/wi-fi/dnur-s2)
Wollte irgendwann nochmal gegentesten ob das in der Praxis auch soviel schlechter aussieht.
War gestern fliegen und wollte endlich mal einen ruckelfreien FPV-Flug genießen.
Nachdem ich erst nur Pixelbrei hatte, dachte ich ich muss die Bitrate noch ein bisschen hochsetzen. Also Bitrate auf 5.5Mbit gestellt und noch mal testen.
Danach hat nichts mehr funktioniert. Daheim hat sich rausgestellt dass der WN722N Stick abgeraucht sein muss, er hat einen Kurzschluss.
Jetzt habe ich gerade einen neuen Stick angelötet und mal getestet wie warm das ganze wird. Der Stick wird jedenfalls an der Metallkappe gut warm, wärmer als die Empfängersticks mit normalem Image und langsamen Blinkverhalten.
Auch der Broadcom Chip auf dem Odroid W wird extrem warm.
Wie habt ihr das Problem mit der Wärmeentwicklung gelöst? Ich habe alles sehr eng aufeinander gestapelt, die Cam ist mit Heiskleber quasi direkt auf den Broadcom geklebt und der Spannungswandler mit Servotape auf die Metallkappe vom Wifistick geklebt. Also quasi alles was heiß wird direkt aufeinander
Mit dem normalen Image ging es noch gut mit der Erwärmung, denke auch weil der Raspberry bei Hitze einfach runtergeregelt hat, mit dem EZ Image scheint es aber auf Dauer nicht gut zu gehen.
Nachdem ich erst nur Pixelbrei hatte, dachte ich ich muss die Bitrate noch ein bisschen hochsetzen. Also Bitrate auf 5.5Mbit gestellt und noch mal testen.
Danach hat nichts mehr funktioniert. Daheim hat sich rausgestellt dass der WN722N Stick abgeraucht sein muss, er hat einen Kurzschluss.
Jetzt habe ich gerade einen neuen Stick angelötet und mal getestet wie warm das ganze wird. Der Stick wird jedenfalls an der Metallkappe gut warm, wärmer als die Empfängersticks mit normalem Image und langsamen Blinkverhalten.
Auch der Broadcom Chip auf dem Odroid W wird extrem warm.
Wie habt ihr das Problem mit der Wärmeentwicklung gelöst? Ich habe alles sehr eng aufeinander gestapelt, die Cam ist mit Heiskleber quasi direkt auf den Broadcom geklebt und der Spannungswandler mit Servotape auf die Metallkappe vom Wifistick geklebt. Also quasi alles was heiß wird direkt aufeinander
Mit dem normalen Image ging es noch gut mit der Erwärmung, denke auch weil der Raspberry bei Hitze einfach runtergeregelt hat, mit dem EZ Image scheint es aber auf Dauer nicht gut zu gehen.
Temperatur vom Pi und TX Sticks ist hoeher durch das übertakten und die höhere Sendeleistung. Habe selber mit 051NHA, 722N, 036NHA und CSL 300 als TX und diversen Pis über Nacht getestet, lief alles stabil. WLAN Karten wurden an den wärmsten Stellen zwischen ca. 45 (NHA) und 60 Grad (CSL300). Pi je nach Modell bis ca. 70 Grad (ohne Kühlkörper). Natürlich bei normaler Zimmertemperatur am Schreibtisch.
Der Pi regelt ab 85 Grad CPU temp automatisch die Taktfrequenz herunter.
Beim nächsten Image werden die default Overclock settings etwas niedriger sein ... Bis dahin kann das ja jeder in der config.txt nach belieben ändern.
Schalonsus: Wenn man Elektronik zu heiss werden lässt, gibt's nunmal Probleme. Hat nix mit dem Image zu tun.
Der Pi regelt ab 85 Grad CPU temp automatisch die Taktfrequenz herunter.
Beim nächsten Image werden die default Overclock settings etwas niedriger sein ... Bis dahin kann das ja jeder in der config.txt nach belieben ändern.
Schalonsus: Wenn man Elektronik zu heiss werden lässt, gibt's nunmal Probleme. Hat nix mit dem Image zu tun.
- Status
