EZ-Wifibroadcast, HD FPV in günstig und einfach
- Themenstarter rodizio
- Beginndatum
- Status
Ich nehme immer das Ladekabel von meinem Telefon, glaube das ist ein ganz normales USB-A auf Micro-USB Kabel.
stxShadow:
Macht die Geschichte mit den beiden 036NHA RX-Karten noch Probleme?
Habe es endlich geschafft das nachzuvollziehen und einen seltsamen Kernel- oder Atheros-Treiber Bug gefunden der damit zusammenhängen könnte.
Scheinbar mögen die Karten das manchmal nicht, wenn sie in den promiscous mode geschaltet werden vom rx Programm. Wenn ich den rx Prozess immer wieder neustarte, dann schmiert bei mehr als zwei angesteckten Atheros Karten manchmal eine ab (nach dem 5. mal oder so, und auch nicht immer). Praktischerweise ist der promiscous mode bei wifi Karten im Monitor Mode eh' nicht notwendig, weil die Karten sowieso alles weiterleiten. Habe das daher testweise mal abgeschaltet in der rx.c.
Falls Du das mal versuchen willst:
- einloggen per ssh mit root/raspberry oder lokal per usb keyboard und mit alt-F10 auf TTY10 schalten
- "rw"
- "cd wifibroadcast"
- "nano rx.c"
Diese Zeile suchen (ungefähr bei Zeile 100):
und dort die 1 in eine 0 ändern:
- speichern und beenden (CTRL-X und "Y")
- "make"
- "reboot"
Das sollte hoffentlich das Problem beheben was ich bei Dir in den Screenshots gesehen habe, dass eine Karte läuft, aber die zweite Karte nur ein, zwei Sekunden und dann wieder aufhört.
stxShadow:
Macht die Geschichte mit den beiden 036NHA RX-Karten noch Probleme?
Habe es endlich geschafft das nachzuvollziehen und einen seltsamen Kernel- oder Atheros-Treiber Bug gefunden der damit zusammenhängen könnte.
Scheinbar mögen die Karten das manchmal nicht, wenn sie in den promiscous mode geschaltet werden vom rx Programm. Wenn ich den rx Prozess immer wieder neustarte, dann schmiert bei mehr als zwei angesteckten Atheros Karten manchmal eine ab (nach dem 5. mal oder so, und auch nicht immer). Praktischerweise ist der promiscous mode bei wifi Karten im Monitor Mode eh' nicht notwendig, weil die Karten sowieso alles weiterleiten. Habe das daher testweise mal abgeschaltet in der rx.c.
Falls Du das mal versuchen willst:
- einloggen per ssh mit root/raspberry oder lokal per usb keyboard und mit alt-F10 auf TTY10 schalten
- "rw"
- "cd wifibroadcast"
- "nano rx.c"
Diese Zeile suchen (ungefähr bei Zeile 100):
Code:
interface->ppcap = pcap_open_live(name, 2048, [B]1[/B], -1, szErrbuf);
Code:
interface->ppcap = pcap_open_live(name, 2048, [B]0[/B], -1, szErrbuf);- "make"
- "reboot"
Das sollte hoffentlich das Problem beheben was ich bei Dir in den Screenshots gesehen habe, dass eine Karte läuft, aber die zweite Karte nur ein, zwei Sekunden und dann wieder aufhört.
Hi Leute,
ich wollte das mit dem USB tethering auch mal ausprobieren.
Aber es steht nur die ganze Zeit, dass er ein Android Gerät sucht
Ich habe auf dem Tablet (Samsung Note 10.1, dass alte) die neuste Version von dem Player für Android 4.X installiert.
Das Tablet habe ich dann mit dem normalen USB Ladekabel mit dem Raspberry verbunden, wo drauf hin ich von dem Tablet gefragt werde ob als Mediengerät (MTP) oder als Kamera (PTP) verbunden werden soll.
Wenn ich in die App gehe, habe ich einfach nur ein schwarzes Bild.
Habt ihr vielleicht einen Tipp für mich?
LG
Jan
Edit:
Okay ich habe herausgefunden, dass man das USB tethering anschalten muss!
Jetzt hat er auch mein Tablet gefunden
und er schreibt:
Starting RX . . . . (FEC: 8/4/1024)
Aber immer noch kein Bild
Edit:
Problem ist gelöst
ich wollte das mit dem USB tethering auch mal ausprobieren.
Aber es steht nur die ganze Zeit, dass er ein Android Gerät sucht
Ich habe auf dem Tablet (Samsung Note 10.1, dass alte) die neuste Version von dem Player für Android 4.X installiert.
Das Tablet habe ich dann mit dem normalen USB Ladekabel mit dem Raspberry verbunden, wo drauf hin ich von dem Tablet gefragt werde ob als Mediengerät (MTP) oder als Kamera (PTP) verbunden werden soll.
Wenn ich in die App gehe, habe ich einfach nur ein schwarzes Bild.
Habt ihr vielleicht einen Tipp für mich?
LG
Jan
Edit:
Okay ich habe herausgefunden, dass man das USB tethering anschalten muss!
Jetzt hat er auch mein Tablet gefunden
und er schreibt:
Starting RX . . . . (FEC: 8/4/1024)
Aber immer noch kein Bild
Edit:
Problem ist gelöst
Zuletzt bearbeitet:
Ich habe noch eine weitere Frage zu dem Aufbau der Videoübertragung.
Da ich den Copter auch mal dazu verwenden will etwas zu filmen und dies mit einer sjcam 4000 wifi machen will.
Wäre es natürlich gut, wenn ich das live Bild von der Sj4000 übertragen könnte, also anstatt der pi cam.
Nun existiert ja für ca. 80€ ein HDMI to CSI 15pol Platine, so dass man die Sj4000 direkt an den Raspberry anschließen kann.
Ist das alles Plug and Play? Und funktioniert mit unserer Software?
Oder sollte man da lieber die Finger von lassen?
Da ich den Copter auch mal dazu verwenden will etwas zu filmen und dies mit einer sjcam 4000 wifi machen will.
Wäre es natürlich gut, wenn ich das live Bild von der Sj4000 übertragen könnte, also anstatt der pi cam.
Nun existiert ja für ca. 80€ ein HDMI to CSI 15pol Platine, so dass man die Sj4000 direkt an den Raspberry anschließen kann.
Ist das alles Plug and Play? Und funktioniert mit unserer Software?
Oder sollte man da lieber die Finger von lassen?
Ich habe diesen Adapter in Verwendung und es funktioniert einwandfrei mit dem Pi2 und Pi A+.
Leider musste ich feststellen, dass es mit meinem Pi Zero nicht funktioniert! Der Zero braucht ein Adapter-Flachbandkabel, da er einen kleineren Anschluss für die Kamera hat.
Bei dem Adapter war ein Kabel dabei, mit dem geht es wunderbar am Pi A+ und am Pi2. Nehme ich allerdings ein identisches Kabel (ist etwas länger), dann funktioniert es nicht. Ich habe leider kein Ahnung weshalb, denn die Pi Cam funktioniert mit dem Kabel. Also kann es eigentlich nicht defekt sein.
Zusammengefasst:
Kabel das bei der HDMI to CSI Bridge dabei war:
- funktioniert mit der Bridge und mit der Pi Cam
Kabel, welches ich gekauft habe (identisch mit obigem, nur etwas länger):
- funktioniert NICHT mit der Bridge, funktioniert aber mit der Pi Cam
Kabel, welches als offizielles Zubehör für den Pi Zero (kleinerer Anschluss) verkauft wird:
- funktioniert NICHT mit der Bridge, funktioniert aber mit der Pi Cam
Hat da jemand ne Idee woran das liegen könnte?
Leider musste ich feststellen, dass es mit meinem Pi Zero nicht funktioniert! Der Zero braucht ein Adapter-Flachbandkabel, da er einen kleineren Anschluss für die Kamera hat.
Bei dem Adapter war ein Kabel dabei, mit dem geht es wunderbar am Pi A+ und am Pi2. Nehme ich allerdings ein identisches Kabel (ist etwas länger), dann funktioniert es nicht. Ich habe leider kein Ahnung weshalb, denn die Pi Cam funktioniert mit dem Kabel. Also kann es eigentlich nicht defekt sein.
Zusammengefasst:
Kabel das bei der HDMI to CSI Bridge dabei war:
- funktioniert mit der Bridge und mit der Pi Cam
Kabel, welches ich gekauft habe (identisch mit obigem, nur etwas länger):
- funktioniert NICHT mit der Bridge, funktioniert aber mit der Pi Cam
Kabel, welches als offizielles Zubehör für den Pi Zero (kleinerer Anschluss) verkauft wird:
- funktioniert NICHT mit der Bridge, funktioniert aber mit der Pi Cam
Hat da jemand ne Idee woran das liegen könnte?
Okay super
Also das mit dem Kabel ist ja merkwürdig, denke das wird daran liegen,
dass ein längeres Kabel natürlich mehr Störungen einfängt. ( vielleicht irgendwie isolieren?)
Wenn die Kabel sonst identisch sind, gibt es ja keine andere Erklärung.
Darf man fragen, wo du den Adapter gekauft hast? Und wie teuer der war?
Also das mit dem Kabel ist ja merkwürdig, denke das wird daran liegen,
dass ein längeres Kabel natürlich mehr Störungen einfängt. ( vielleicht irgendwie isolieren?)
Wenn die Kabel sonst identisch sind, gibt es ja keine andere Erklärung.
Darf man fragen, wo du den Adapter gekauft hast? Und wie teuer der war?
Den Adapter gibt es hier zu kaufen:
http://www.auvidea.eu/index.php/theme-styles/2014-12-30-22-32-06/b101
http://www.auvidea.eu/index.php/theme-styles/2014-12-30-22-32-06/b101
Ich habe den Adapter auch bei auvidea gekauft.
Mir ist noch aufgefallen, dass bei dem Kabel bei dem die bridge funktioniert, die "Power-LED" auf dem Board leuchtet, bei den anderen nicht.
Augenscheinlich sind aber alle Pins belegt. Es gehen gleich viele Leiterbahnen von der einen Seite zur anderen, wie auch "Pins" vorhanden sind.
Mir ist noch aufgefallen, dass bei dem Kabel bei dem die bridge funktioniert, die "Power-LED" auf dem Board leuchtet, bei den anderen nicht.
Augenscheinlich sind aber alle Pins belegt. Es gehen gleich viele Leiterbahnen von der einen Seite zur anderen, wie auch "Pins" vorhanden sind.
Ich hab gerade Zeit und qüäle mich mit 2 eigentlich nicht kompatiblen Sticks, die allerdings qualitativ sehr gut wären.
Treiber habe ich kompiliert und das EZ Image erkennt sie auch beim Start, allerdings gibt es Probleme beim Umschalten der Frequenz.
Hat irgendjemand von euch eine wie auch immer geartete Beschreibung wie der Aufbau der Skripte aussieht?
Ich denke ich muss bei der Frequenzumschalterei etwas ändern wenn der T2H Archer Stick erkannt wird.
Rodizio, Du hast doch mal geschrieben das Du die Sendeleistung beim 51H etwas zurückgenommen hast, kannst Du mir bitte schreiben welcher Skript das macht?
Ich bin jetzt schon länger nicht mehr geflogen, hab gerade etwas anderes "am Bein"...aber ich hatte da ein Problem mit dem Gimbal, offensichtlich flattert das Folienkabel etwas im Fahrtwind und das Videobild ist ganz leicht zittrig.
Anders verlegen geht nicht, weil ich ein 3 Achsen Gimbal habe.
Daher will ich doch nochmal das AV Signal der Kamera abgreifen und über einen Easycap Stick einspeisen.
Wie wird denn erkannt das eine Raspicam angeschlossen ist und dann auf TX umschaltet? ich müsste da natürlich etwas ändern, da ja keine Raspicam mitfliegt.
Ich habe übrigens auf den aktuellen Kernel aktualisiert (4.4.32), geht einwandfrei.
Was mich allerdings echt nervt ist das Tastaturlayout das bei raspi-config geändert werden kann, aber beim Reboot ist wieder das englische Layout drin.
Wenn man einiges ändern möchte ist es nicht gerade ergonomisch, könnte man das nächste IMG bitte nicht ganz so derb kastrieren?
Treiber habe ich kompiliert und das EZ Image erkennt sie auch beim Start, allerdings gibt es Probleme beim Umschalten der Frequenz.
Hat irgendjemand von euch eine wie auch immer geartete Beschreibung wie der Aufbau der Skripte aussieht?
Ich denke ich muss bei der Frequenzumschalterei etwas ändern wenn der T2H Archer Stick erkannt wird.
Rodizio, Du hast doch mal geschrieben das Du die Sendeleistung beim 51H etwas zurückgenommen hast, kannst Du mir bitte schreiben welcher Skript das macht?
Ich bin jetzt schon länger nicht mehr geflogen, hab gerade etwas anderes "am Bein"...aber ich hatte da ein Problem mit dem Gimbal, offensichtlich flattert das Folienkabel etwas im Fahrtwind und das Videobild ist ganz leicht zittrig.
Anders verlegen geht nicht, weil ich ein 3 Achsen Gimbal habe.
Daher will ich doch nochmal das AV Signal der Kamera abgreifen und über einen Easycap Stick einspeisen.
Wie wird denn erkannt das eine Raspicam angeschlossen ist und dann auf TX umschaltet? ich müsste da natürlich etwas ändern, da ja keine Raspicam mitfliegt.
Ich habe übrigens auf den aktuellen Kernel aktualisiert (4.4.32), geht einwandfrei.
Was mich allerdings echt nervt ist das Tastaturlayout das bei raspi-config geändert werden kann, aber beim Reboot ist wieder das englische Layout drin.
Wenn man einiges ändern möchte ist es nicht gerade ergonomisch, könnte man das nächste IMG bitte nicht ganz so derb kastrieren?
Zuletzt bearbeitet:
Okay , also lipo nicht direkt abschließen
Muss ich mir extra wegen der Spannung ein OSD kaufen, oder kann man das auch irgendwie von der Naza v2 oder dem Gimbal
abzwacken? ( Beide zeigen in der Software am Pc die Spannung an)
Oder wenn das nicht geht, was für ein OSD verwendet man denn, bzw ist kompatibel mit WifiBroadcast?
Muss ich mir extra wegen der Spannung ein OSD kaufen, oder kann man das auch irgendwie von der Naza v2 oder dem Gimbal
abzwacken? ( Beide zeigen in der Software am Pc die Spannung an)
Oder wenn das nicht geht, was für ein OSD verwendet man denn, bzw ist kompatibel mit WifiBroadcast?
Ich seh schon, Du bist noch recht neu in der Materie Macht nichts, bei mir z.B. ist es auch noch nicht lange her.
Also, ein OSD visualisiert lediglich Telemetriedaten als Overlay im Videobild, setzt also wiederum voraus das es auch Telemetriedaten bekommt. Da EZ ein OSD an Bord hat, brauchst Du es nicht.
Du brauchst etwas das Dir die Telemetriedaten nach FrSky oder Pixhawk System übersetzt und dieses Signal wird dann zum Raspberry am RX Pin des GPIO angeschlossen.
Ich hab mit DJI Zeugs noch nie was an Hut gehabt, aber so auf die schnelle hab ich am Handy geschaut und etwas gefunden das vielleicht das sein könnte was Du brauchst:
http://fpv-community.de/showthread.php?44430-Telemetrie-Adapter-Naza-gt-FrSky-Taranis
Zumindest weisst Du nun was Du in etwa brauchst.
Nachtrag:
Falls Du kein Bock auf Selbstbau hast:
http://anysense.de/produkte/anysense-telemetrie-modul/
Macht nichts, bei mir z.B. ist es auch noch nicht lange her.Also, ein OSD visualisiert lediglich Telemetriedaten als Overlay im Videobild, setzt also wiederum voraus das es auch Telemetriedaten bekommt. Da EZ ein OSD an Bord hat, brauchst Du es nicht.
Du brauchst etwas das Dir die Telemetriedaten nach FrSky oder Pixhawk System übersetzt und dieses Signal wird dann zum Raspberry am RX Pin des GPIO angeschlossen.
Ich hab mit DJI Zeugs noch nie was an Hut gehabt, aber so auf die schnelle hab ich am Handy geschaut und etwas gefunden das vielleicht das sein könnte was Du brauchst:
http://fpv-community.de/showthread.php?44430-Telemetrie-Adapter-Naza-gt-FrSky-Taranis
Zumindest weisst Du nun was Du in etwa brauchst.
Nachtrag:
Falls Du kein Bock auf Selbstbau hast:
http://anysense.de/produkte/anysense-telemetrie-modul/
Zuletzt bearbeitet:
Okay, Danke für die Info
Also dieses Teil würde funktionieren: ?
http://www.fpv1.de/fpv1-zaggometry-naza2frsky-taranis-telemetrie-adapter.html
Wodrin unterscheidet sich dein verlinktes Produkt?
Also dieses Teil würde funktionieren: ?
http://www.fpv1.de/fpv1-zaggometry-naza2frsky-taranis-telemetrie-adapter.html
Wodrin unterscheidet sich dein verlinktes Produkt?
Deepflights:
Wegen der Skripte: Ist alles in /root/.profile. Sind auch recht viele Kommentare drin, sollte recht selbst-erklärend sein. Raspicam Erkennung wird da auch gemacht, musst mal nach dem "vcgencmd get_cam" Befehl (oder so ähnlich) suchen.
Kannst Du mal bitte "dmesg" und "iw list" eingeben mit der Karte angeschlossen und hier die Ausgabe posten? Eigentlich sollte die Kanalumschaltung mit iwconfig immer gehen. Kann es sein dass er beim Monitor mode hängt?
Sendeleistung wurde für alle rt2800 Karten reduziert (bzw. wieder auf default-Sendeleistung gesetzt), gibt leider keine Möglichkeit die Karten zu unterscheiden. Kannst Du über den Modulparameter des rt2800 Moduls einstellen, /etc/modprobe.d/rt2800.conf. txpower=0 ist der defaultwert, txpower=6 wären 6db mehr, txpower=-6 wären 6db weniger.
Wegen dem 4.4.32er Kernel: Hast Du den auch wieder gepatcht?
Habe die 1.4er die in Arbeit ist (und eigentlich schon lange fertig sein sollte ...) auch gerade auf 4.4.32 aktualisiert, scheint bis jetzt okay zu sein. Nur grundsätzlich würde ich das nicht ohne Not machen, die bauen da gerne mal irgendwelche neuen seltsamen Bugs ein ...
War da bei Frsky Telemetrie nicht irgendwas mit invertiertem Signal? Laufen diese Frsky Adapter so direkt an einen normalen seriellen Port? Bin mir gerade nicht sicher ...
Wegen der Skripte: Ist alles in /root/.profile. Sind auch recht viele Kommentare drin, sollte recht selbst-erklärend sein. Raspicam Erkennung wird da auch gemacht, musst mal nach dem "vcgencmd get_cam" Befehl (oder so ähnlich) suchen.
Kannst Du mal bitte "dmesg" und "iw list" eingeben mit der Karte angeschlossen und hier die Ausgabe posten? Eigentlich sollte die Kanalumschaltung mit iwconfig immer gehen. Kann es sein dass er beim Monitor mode hängt?
Sendeleistung wurde für alle rt2800 Karten reduziert (bzw. wieder auf default-Sendeleistung gesetzt), gibt leider keine Möglichkeit die Karten zu unterscheiden. Kannst Du über den Modulparameter des rt2800 Moduls einstellen, /etc/modprobe.d/rt2800.conf. txpower=0 ist der defaultwert, txpower=6 wären 6db mehr, txpower=-6 wären 6db weniger.
Wegen dem 4.4.32er Kernel: Hast Du den auch wieder gepatcht?
Habe die 1.4er die in Arbeit ist (und eigentlich schon lange fertig sein sollte ...) auch gerade auf 4.4.32 aktualisiert, scheint bis jetzt okay zu sein. Nur grundsätzlich würde ich das nicht ohne Not machen, die bauen da gerne mal irgendwelche neuen seltsamen Bugs ein ...
War da bei Frsky Telemetrie nicht irgendwas mit invertiertem Signal? Laufen diese Frsky Adapter so direkt an einen normalen seriellen Port? Bin mir gerade nicht sicher ...
Ich hab schon angefangen zu suchen, aber /root/.profile da war ich noch nicht.
Ich gehe gleich nochmal dran und poste die beiden Meldungen.
Das komische ist, bei "ifconfig" ist der Name des Anschlusses ist nicht mehr "wlan0" sondern "000000000" da liegt irgendwo der Hund begraben wette ich.
Der Monitormodus ist es nicht, laut Meldung beim hochfahren wird der Stick erkannt, auf Monitormodus geschaltet und es geht dann an die Frequenzumschaltung, da bringt er erst den Fehler it Code 92 oder 22, hab ich grad nicht mehr so im Kopf.
Vorhin habe ich den gleichen Treiber mit einem neuen Jessie-light Image getestet, da geht es einwandfrei, zumindest kann ich den WLAN Stick im heimischen WLAN nutzen, in beiden Frequenzbereichen.
Auch wird er da korrekt als Wlan 0 oder 1 angezeigt, je nach dem ob ich den WLAN Chip des PI3 blacklisted habe ober nicht.
Auf alle Fälle schreibe ich später noch etwas dazu, ich habe damals diese Sticks gekauft ohne zu wissen die gar nicht kompatibel sind.
Die haben mich aber unter Windows ziemlich überzeugt, die sind schnell und sind offensichtlich qualitativ viel besser als die welche hier für den 5,8 Ghz Bereich nutzbar sind, daher hats in mir den "Forscherdrang" geweckt. Da ich zwei habe, könnte ich zudem gleich ein Diversity machen.
Der Kernelupdate war nötig da ich zunächst einen anderen Treiber für die T2UH Sticks hatte, der war unter der 4.4.11#18 welche das EZ Image hat nicht ums verrecken kompilierbar, da hatte ich irgendwann das Näschen voll und hab einfach das Update drübergebügelt.
Es ist aber weder schneller noch stabiler noch sonst irgendwas, also man merkt nicht viel, ausser wenn ich den Raspi am Netzteil betreibe das es nun ein Blitzsymbol gibt anstatt des bunten Rechtecks wenn der Strom nicht ganz reicht.
Wenn Du eh noch am Imagebasteln bist, kannst Du BITTE eine deutsche Tastatur konfigurieren? Ich zumindest tippe (fast) blind, aber die Ami-Tasta geht mir echt an den Senkel, da bin ich sicher nicht alleine.
Ich halt mich mal ran an der Sache, vielleicht könnte mal ja sogar beim nächsten IMG schon die WLAN-Stick Familie vergrössern.
Wg der Sendeleistung:
In der Datei war ich sogar schon, ich wusste aber nicht in welche Richtung es geht, ausserdem möchte ich wenn dann auch mal mit der Sendeleistung der T2UH Sticks spielen, mir geht es zunächst ja nur wie denn überhaupt das Prinzip funktioniert.
Besagte Sticks habe einen eigenen Ordner unter /etc mal sehen wie man da etwas per Skript später umkonfigurieren kann.
Telemetrie:
Ich hab keinen blassen Schimmer wie die original FrSky Daten aussehen, ich übersetze ja Mavlink -> HOTT und jage das in den Telemetrieport meines Empfängers.
Ich habe aber mal Gaudihalber den Telemetrieausgang des Pixhawk auf FrSky gesetzt und dann im Skript statt Mavlink FrSky eingetragen, ging ohne Probleme, ich hatte am OSD die Daten.
So, jetzt gehe ich wieder in mein "Kinderzimmer", mal sehen wie weit ich mit den Sticks komme.
Ich gehe gleich nochmal dran und poste die beiden Meldungen.
Das komische ist, bei "ifconfig" ist der Name des Anschlusses ist nicht mehr "wlan0" sondern "000000000" da liegt irgendwo der Hund begraben wette ich.
Der Monitormodus ist es nicht, laut Meldung beim hochfahren wird der Stick erkannt, auf Monitormodus geschaltet und es geht dann an die Frequenzumschaltung, da bringt er erst den Fehler it Code 92 oder 22, hab ich grad nicht mehr so im Kopf.
Vorhin habe ich den gleichen Treiber mit einem neuen Jessie-light Image getestet, da geht es einwandfrei, zumindest kann ich den WLAN Stick im heimischen WLAN nutzen, in beiden Frequenzbereichen.
Auch wird er da korrekt als Wlan 0 oder 1 angezeigt, je nach dem ob ich den WLAN Chip des PI3 blacklisted habe ober nicht.
Auf alle Fälle schreibe ich später noch etwas dazu, ich habe damals diese Sticks gekauft ohne zu wissen die gar nicht kompatibel sind.
Die haben mich aber unter Windows ziemlich überzeugt, die sind schnell und sind offensichtlich qualitativ viel besser als die welche hier für den 5,8 Ghz Bereich nutzbar sind, daher hats in mir den "Forscherdrang" geweckt. Da ich zwei habe, könnte ich zudem gleich ein Diversity machen.
Der Kernelupdate war nötig da ich zunächst einen anderen Treiber für die T2UH Sticks hatte, der war unter der 4.4.11#18 welche das EZ Image hat nicht ums verrecken kompilierbar, da hatte ich irgendwann das Näschen voll und hab einfach das Update drübergebügelt.
Es ist aber weder schneller noch stabiler noch sonst irgendwas, also man merkt nicht viel, ausser wenn ich den Raspi am Netzteil betreibe das es nun ein Blitzsymbol gibt anstatt des bunten Rechtecks wenn der Strom nicht ganz reicht.
Wenn Du eh noch am Imagebasteln bist, kannst Du BITTE eine deutsche Tastatur konfigurieren? Ich zumindest tippe (fast) blind, aber die Ami-Tasta geht mir echt an den Senkel, da bin ich sicher nicht alleine.
Ich halt mich mal ran an der Sache, vielleicht könnte mal ja sogar beim nächsten IMG schon die WLAN-Stick Familie vergrössern.
Wg der Sendeleistung:
In der Datei war ich sogar schon, ich wusste aber nicht in welche Richtung es geht, ausserdem möchte ich wenn dann auch mal mit der Sendeleistung der T2UH Sticks spielen, mir geht es zunächst ja nur wie denn überhaupt das Prinzip funktioniert.
Besagte Sticks habe einen eigenen Ordner unter /etc mal sehen wie man da etwas per Skript später umkonfigurieren kann.
Telemetrie:
Ich hab keinen blassen Schimmer wie die original FrSky Daten aussehen, ich übersetze ja Mavlink -> HOTT und jage das in den Telemetrieport meines Empfängers.
Ich habe aber mal Gaudihalber den Telemetrieausgang des Pixhawk auf FrSky gesetzt und dann im Skript statt Mavlink FrSky eingetragen, ging ohne Probleme, ich hatte am OSD die Daten.
So, jetzt gehe ich wieder in mein "Kinderzimmer", mal sehen wie weit ich mit den Sticks komme.
Zuletzt bearbeitet:
Nachdem ich die halbe Nacht herumprobiert habe muss ich gestehen, ich bringe die Sticks nicht zum laufen..
Es scheint keine Möglichkeit zu geben eine Frequenzumschaltung zu machen wie es die anderen Sticks können welche wir nutzen.
Komischerweise wird auch der Name der Verbindung nicht, wie im /root/.profile skript angegeben, in die MAC-Nummer umbenannt, obwohl der dazugehörige Befehl, manuell ausgeführt, funktioniert.
Ich werde noch eines versuchen, Mediatek direkt anzuschreiben und ihnen das Problem darlegen, viel Hoffnung habe ich allerdings nicht.
So schade, denn die Sticks laufen als normale WLAN Sticks am Rasperry einwandfrei, der Treiber würde also passen.
Ich poste trotzdem heute Abend noch die Dateien die Du haben wolltest, die "iw list" ist aber komplett anders, dafür hab ich gesehen das die Sticks sogar bis 6 Ghz könnten.....
Da mein Treiber nicht auf das original Image passte, habe ich wieder auf 4.4.32 upgedatet, dabei fiel mir aber etwas auf das Du unbedingt beachten solltest:
Wenn die TX-Verbindung abreisst und sich wieder verdindet dann kommen zwar die Telemetriedaten wieder an, aber KEIN BILD!
Es scheint also doch etwas mit den neuen Kernel im argen zu liegen das für unsere Anwendung vielleicht "nicht ganz so ideal" ist.
Ich bin draufgekommen als ich mit den versch. Sendeleistungen gespielt habe, da liess ich den RX einfach laufen und bootete nur den TX, der hat noch das 4.4.11 drauf.
Bild kam wie schon gesagt, nach Neuaufbau der Verbindung nicht mehr an, erst nachde, ich RX ebenfalls neu gebootet habe war das Bild da.
Schau doch mal bitte wenn Du 1.4 soweit lauffähig hast, ob Du es nachvollziehen kannst.
Bei der Sendeleistungseinstellung bin ich gerade etwas verwirrt, denn so wie Du es beschrieben hast scheint es ein Problem zu geben mit dem 51H, normalerweise sollte doch der dB Wert der Telemetrieanzeige sich ändern wenn ich in der Datei den Wert ändere oder?
Ich bin mit den Werten sogar auf -30 gewesen, die Unterschiede waren aber keineswegs analog dazu, oder ich habe einen Denkfehler drin?
Ich habe zu dem Thema zwar etwas ähnliches gefunden, allerdings ändern die dort den TX über "iwconfig", habe ich versucht, aber da fehlt wohl etwas in dem Image, Ifup und Ifdown gehen nämlich auch nicht.
War das nicht irgendein Paket mit Netzwerkmanagement oder so?
Auf alle Fälle war der Hinweis auf den Startskript für mich sehr hilfreich, denn nun habe ich endlich die Stelle gefunden bei der Raspivid gestartet wird. Danke!
Da ich ja ein AV Signal einspeisen will, muss ich dort anstatt Raspivid den Mplayer starten, mal sehen wie ich die Sache drehen kann. Zumindest weiss ich jetzt wo ich Hand anlegen muss.
Gibt es bei "dmesg" irgendeine Möglichkeit zu filtern? die Hilfedatei ist dazu für mich etwas verwirrend, die Ausgabe ist nämlich trotz "dmesg -C" und dann Stick einstecken immer noch ziemlich lang, oder muss ich das Ergebniss am Editor bearbeiten?
Es scheint keine Möglichkeit zu geben eine Frequenzumschaltung zu machen wie es die anderen Sticks können welche wir nutzen.
Komischerweise wird auch der Name der Verbindung nicht, wie im /root/.profile skript angegeben, in die MAC-Nummer umbenannt, obwohl der dazugehörige Befehl, manuell ausgeführt, funktioniert.
Ich werde noch eines versuchen, Mediatek direkt anzuschreiben und ihnen das Problem darlegen, viel Hoffnung habe ich allerdings nicht.
So schade, denn die Sticks laufen als normale WLAN Sticks am Rasperry einwandfrei, der Treiber würde also passen.
Ich poste trotzdem heute Abend noch die Dateien die Du haben wolltest, die "iw list" ist aber komplett anders, dafür hab ich gesehen das die Sticks sogar bis 6 Ghz könnten.....
Da mein Treiber nicht auf das original Image passte, habe ich wieder auf 4.4.32 upgedatet, dabei fiel mir aber etwas auf das Du unbedingt beachten solltest:
Wenn die TX-Verbindung abreisst und sich wieder verdindet dann kommen zwar die Telemetriedaten wieder an, aber KEIN BILD!
Es scheint also doch etwas mit den neuen Kernel im argen zu liegen das für unsere Anwendung vielleicht "nicht ganz so ideal" ist.
Ich bin draufgekommen als ich mit den versch. Sendeleistungen gespielt habe, da liess ich den RX einfach laufen und bootete nur den TX, der hat noch das 4.4.11 drauf.
Bild kam wie schon gesagt, nach Neuaufbau der Verbindung nicht mehr an, erst nachde, ich RX ebenfalls neu gebootet habe war das Bild da.
Schau doch mal bitte wenn Du 1.4 soweit lauffähig hast, ob Du es nachvollziehen kannst.
Bei der Sendeleistungseinstellung bin ich gerade etwas verwirrt, denn so wie Du es beschrieben hast scheint es ein Problem zu geben mit dem 51H, normalerweise sollte doch der dB Wert der Telemetrieanzeige sich ändern wenn ich in der Datei den Wert ändere oder?
Ich bin mit den Werten sogar auf -30 gewesen, die Unterschiede waren aber keineswegs analog dazu, oder ich habe einen Denkfehler drin?
Ich habe zu dem Thema zwar etwas ähnliches gefunden, allerdings ändern die dort den TX über "iwconfig", habe ich versucht, aber da fehlt wohl etwas in dem Image, Ifup und Ifdown gehen nämlich auch nicht.
War das nicht irgendein Paket mit Netzwerkmanagement oder so?
Auf alle Fälle war der Hinweis auf den Startskript für mich sehr hilfreich, denn nun habe ich endlich die Stelle gefunden bei der Raspivid gestartet wird. Danke!
Da ich ja ein AV Signal einspeisen will, muss ich dort anstatt Raspivid den Mplayer starten, mal sehen wie ich die Sache drehen kann. Zumindest weiss ich jetzt wo ich Hand anlegen muss.
Gibt es bei "dmesg" irgendeine Möglichkeit zu filtern? die Hilfedatei ist dazu für mich etwas verwirrend, die Ausgabe ist nämlich trotz "dmesg -C" und dann Stick einstecken immer noch ziemlich lang, oder muss ich das Ergebniss am Editor bearbeiten?
Zuletzt bearbeitet:
- Status
