Befi hat eine Erweiterung geschrieben, mit der ich vom OSD aus die Anzahl der Pakate (komplett und fehlerhaft) auslesen kann. Außerdem wird die Aktuelle Signalstärke mit übergeben. Damit kann ich dann eine Art RSSI anhand der Pakete ermitteln. Werde das im laufe des Tages mal im OSD testen. Würde mich freuen, wenn einer von denen, die schon ein flugfertiges Setup haben das mit dem RSSI dann mal im Flug testen würden. Weil aktuell kann ich noch nicht sagen, ob das RSSI viel über die Videoquali nachher aussagt.
FPV Wifi Broadcasting HD Video - Thread zum Raspberry HD Videolink von Befi
- Themenstarter trailblazer
- Beginndatum
- Status
@der-Frickler, finde ich auch als einen eleganten Lösungsansatz, dann sollte aber eine LED am I/O Port, das setzen des Homepoints anzeigen, oder erst dann der Homepfeil gezeigt werden, wenn er gesetzt ist.
@Rangarid, ich werde mich dann mal um das OSD für NAZA kümmern, damit ich das testen kann, meine WBC-Konfig & mein Copter laufen ja jetzt so, dass ich zufreiden bin und es nutzen kann.
Sagt mir ja auch was über meine Antennen.
@Rangarid, ich werde mich dann mal um das OSD für NAZA kümmern, damit ich das testen kann, meine WBC-Konfig & mein Copter laufen ja jetzt so, dass ich zufreiden bin und es nutzen kann.
Sagt mir ja auch was über meine Antennen.
Willst das Naza Protokoll auf dem Rasp parsen? Ansonsten tuts auch ein Arduino als Dolmetscher nach FrSky Hub was Sam ja schon implementiert hat: http://fpv-community.de/showthread.php?46680-Naza-Telemetrie-f%FCr-FrSky-D4R-II-und-D8R
Der-Frickler, ja ich wollte schon einen Adruino dazwischen machen, weil ich dann eventuell zusätzlich noch ein Ultraschall-Distanzmesser (<4m) und einen Voltage/Current-Sensor für´s Hauptakku, und einen Spannungssensor für´s FPV-Akku einbauen wollte.
Denn in 500m und mehr, höre ich den LiPo-Warner nicht mehr.
Und wenn die Funke mir sagt, dass der Empfännger zu wenig Power hat, reicht es nichtt für den Rückflug.
Deinen Link hatte man mir ja schon vor ein paar Tagen gegeben, bin halt nur noch nicht dazu gekommen, das umzusetzen.
Wird aber in den nächsten Tagen kommen.
Mir war erst mal eine funktionierenden WBC-Verbindung wichtiger, die ich ja jetzt sogar mit für mich guten Latenzwerten habe.
Denn in 500m und mehr, höre ich den LiPo-Warner nicht mehr.
Und wenn die Funke mir sagt, dass der Empfännger zu wenig Power hat, reicht es nichtt für den Rückflug.
Deinen Link hatte man mir ja schon vor ein paar Tagen gegeben, bin halt nur noch nicht dazu gekommen, das umzusetzen.
Wird aber in den nächsten Tagen kommen.
Mir war erst mal eine funktionierenden WBC-Verbindung wichtiger, die ich ja jetzt sogar mit für mich guten Latenzwerten habe.
Kurzes Update.
Ich habe es heute endlich geschafft, 2.3Ghz - 2.4Ghz und 5Ghz HD video zu senden und zu Empfangen.
größte Hürde, war das auf OpenWRT laufen zu bringen....
Verwendete HW Tx ist ein Carambola2 device, der HW-Video-Encoder ist von Auvidea, mit HDMI in.
Auf der Carambola läuft ein angepasstes Image, und ein angepasstes sende Programm.
Wifi Sticks 2.3-2.4 -> TX-Carambola TL-WN722 und am PC (eigenes Lubuntu Backports 4.2.2) auch TL-WN722
Wifi Sticks 5.3 -> TX-Carambola CSL 300 und am PC (eigenes Lubuntu Backports 4.2.2) auch CSL 300
Also, sollte auf dem PI eigentlich auch alles laufen.
P.S. der Trick liegt, denke ich daran, des der RX mit CSL 300 auch auf 54M fixed rate stehen muss, genau so wie der TX.
Zu mindest war das so bei mir...
Gruß
Ich habe es heute endlich geschafft, 2.3Ghz - 2.4Ghz und 5Ghz HD video zu senden und zu Empfangen.
größte Hürde, war das auf OpenWRT laufen zu bringen....
Verwendete HW Tx ist ein Carambola2 device, der HW-Video-Encoder ist von Auvidea, mit HDMI in.
Auf der Carambola läuft ein angepasstes Image, und ein angepasstes sende Programm.
Wifi Sticks 2.3-2.4 -> TX-Carambola TL-WN722 und am PC (eigenes Lubuntu Backports 4.2.2) auch TL-WN722
Wifi Sticks 5.3 -> TX-Carambola CSL 300 und am PC (eigenes Lubuntu Backports 4.2.2) auch CSL 300
Also, sollte auf dem PI eigentlich auch alles laufen.
P.S. der Trick liegt, denke ich daran, des der RX mit CSL 300 auch auf 54M fixed rate stehen muss, genau so wie der TX.
Zu mindest war das so bei mir...
Gruß
Gerade drüber gestolpert:
http://hackaday.com/2015/11/04/digging-hdmi-out-of-udp-packets/
https://danman.eu/blog/reverse-engineering-lenkeng-hdmi-over-ip-extender/
Könnte für euch interessant sein, HDMI in über Netzwerk am PC mit billiger Hardware.
Würde Kopterseitig einen HDMI in am Rasp für ~75USD ermöglichen. Ist halt die Frage ob der LAN port am Rasp fix genug ist und wie die Latenz ist.
http://hackaday.com/2015/11/04/digging-hdmi-out-of-udp-packets/
https://danman.eu/blog/reverse-engineering-lenkeng-hdmi-over-ip-extender/
Könnte für euch interessant sein, HDMI in über Netzwerk am PC mit billiger Hardware.
Würde Kopterseitig einen HDMI in am Rasp für ~75USD ermöglichen. Ist halt die Frage ob der LAN port am Rasp fix genug ist und wie die Latenz ist.
Diesen HDMI extender habe ich bereits.
Funktioniert, und Latenz ist ca. 1-2 frame ! Allerdings machte mir vor ca. 1 Jahr die HW-GPU Anbindung and den Gstreamer
auf einem i.mx6 Schwierigkeiten. Wenn jemand meine Sourcen zum decoden vom Stream haben möchte kein Problem...
Gewicht technisch, ist das sicherlich auch nicht das einfachste...
Eigentlich wollte ich auch nur sagen, es es definitiv geht über 5GHz mit CSL 300 Stick's HD stream zu senden...
Funktioniert, und Latenz ist ca. 1-2 frame ! Allerdings machte mir vor ca. 1 Jahr die HW-GPU Anbindung and den Gstreamer
auf einem i.mx6 Schwierigkeiten. Wenn jemand meine Sourcen zum decoden vom Stream haben möchte kein Problem...
Gewicht technisch, ist das sicherlich auch nicht das einfachste...
Eigentlich wollte ich auch nur sagen, es es definitiv geht über 5GHz mit CSL 300 Stick's HD stream zu senden...
Hab grad mal folgenden Test durchgeführt:
TX sendet Video + Telemetrie auf jeweils einem Kanal (2 Kanäle gesamt)
RX empfängt Video + Telemetrie auf jeweils einem Kanal (2 Kanäle gesamt)
RX sendet Text auf einem Kanal
TX Empfängt Text auf einem Kanal
Sowohl RX als auch TX können zeitgleich als Sender und Empfänger arbeiten. Ob das ganze die Latenz verändert habe ich noch nicht getestet aber zumindest wenn man mit dem Finger vor der Kamera rumschnippt kommt es mir nicht schlechter vor als vorher. Jetzt denkt ihr euch vielleicht warum mache ich das? Das ist ganze einfach... Wenn das Rückfunken zuverlässig funktioniert, könnte man damit so schöne Sachen machen wie Wegpunkte im Flug setzen oder einfach den Flieger über Wifibroadcast steuern. Damit hätten wir eine Bidirektionale Verbindung ohne die Nachteile vom WLAN. Das heißt wir könnten theoretisch auch den Flieger damit steuern. Dadurch könnte man auf 2.4G Video und RC nutzen. Ich werde mal mal ein bisschen weiter experimentieren und sehen wie sich das so auswirkt.
Denke das sollte man aber vielleicht nur mit Autopilot machen... Wer weiß wie stabil das ganze ist.
TX sendet Video + Telemetrie auf jeweils einem Kanal (2 Kanäle gesamt)
RX empfängt Video + Telemetrie auf jeweils einem Kanal (2 Kanäle gesamt)
RX sendet Text auf einem Kanal
TX Empfängt Text auf einem Kanal
Sowohl RX als auch TX können zeitgleich als Sender und Empfänger arbeiten. Ob das ganze die Latenz verändert habe ich noch nicht getestet aber zumindest wenn man mit dem Finger vor der Kamera rumschnippt kommt es mir nicht schlechter vor als vorher. Jetzt denkt ihr euch vielleicht warum mache ich das? Das ist ganze einfach... Wenn das Rückfunken zuverlässig funktioniert, könnte man damit so schöne Sachen machen wie Wegpunkte im Flug setzen oder einfach den Flieger über Wifibroadcast steuern. Damit hätten wir eine Bidirektionale Verbindung ohne die Nachteile vom WLAN. Das heißt wir könnten theoretisch auch den Flieger damit steuern. Dadurch könnte man auf 2.4G Video und RC nutzen. Ich werde mal mal ein bisschen weiter experimentieren und sehen wie sich das so auswirkt.
Denke das sollte man aber vielleicht nur mit Autopilot machen... Wer weiß wie stabil das ganze ist.
Zuletzt bearbeitet:
@Rangarid, habe gerade dein OSD getestet, allerdings habe ich jetzt nurnoch ein slowmotion Stream ohne OSD.
Naze32 gibt Frsky Protokoll aus mit "set telemetry_inversion = 1" und 9600 baud. GPS funktioniert in der Cleanflight GUI.
Kommen auch paar Fehlermeldungen beim TX:
Error opening '/dev/input/event*' : No such file or directory
Starting NTP server: ntpd
Starting OpenBSD Sercure Shell server: sshd
Raspbian GNU/Linux 7 raspberry tty1
stty: invalid argument '-9600'
Try 'stty --help' for more information.
Naze32 gibt Frsky Protokoll aus mit "set telemetry_inversion = 1" und 9600 baud. GPS funktioniert in der Cleanflight GUI.
Kommen auch paar Fehlermeldungen beim TX:
Error opening '/dev/input/event*' : No such file or directory
Starting NTP server: ntpd
Starting OpenBSD Sercure Shell server: sshd
Raspbian GNU/Linux 7 raspberry tty1
stty: invalid argument '-9600'
Try 'stty --help' for more information.
Ja, seriell muss auf beiden Seiten deaktiviert werden, sonst ist die serielle Schnittstelle ja an die Konsole gebunden. Denke man muss das stty auf beiden Seiten setzen. Steht zwar so nich in den Scripten drin die online sind, hab ich aber bei meinen heutigen Tests so gemacht...
Das OSD wird übrigens nicht mit aufgenommen wenn man über USB aufnimmt. Dafür bräuchte man dann ein HDMI-Aufnahmegerät.
Das OSD wird übrigens nicht mit aufgenommen wenn man über USB aufnimmt. Dafür bräuchte man dann ein HDMI-Aufnahmegerät.
Zuletzt bearbeitet:
Ok,
sind denn dann meine Einstellungen an der Naze richtig?
Softserial1 FrSky 9600 Baud
set telemetry_inversion = 1
Habe noch ein paar Unterschiede zwischen deinem und BEfis Skript gefunden. Er startet die OSD Streams mit
./rx -p 1 -b 4 wlan0
und
./tx -b 4 -m 64 -s 2&
Du machst das mit allen Paramtern der Videoübertragung, gibnt es dafür einen Grund?
./rx -p $TELEM_PORT -b $BLOCK_SIZE -r $FECS -f $PACKET_LENGTH $NICS
Hier ist auch noch ein Unterschied:
cat /dev/ttyUSB0 > /tmp/fifo1 &
cat /dev/ttyAMA0 > /tmp/fifo1
da fehtl? das &
naja ich teste erstmal Befi seins, dann seh ich ja ob meine Telemetrie geht.
sind denn dann meine Einstellungen an der Naze richtig?
Softserial1 FrSky 9600 Baud
set telemetry_inversion = 1
Habe noch ein paar Unterschiede zwischen deinem und BEfis Skript gefunden. Er startet die OSD Streams mit
./rx -p 1 -b 4 wlan0
und
./tx -b 4 -m 64 -s 2&
Du machst das mit allen Paramtern der Videoübertragung, gibnt es dafür einen Grund?
./rx -p $TELEM_PORT -b $BLOCK_SIZE -r $FECS -f $PACKET_LENGTH $NICS
Hier ist auch noch ein Unterschied:
cat /dev/ttyUSB0 > /tmp/fifo1 &
cat /dev/ttyAMA0 > /tmp/fifo1
da fehtl? das &
naja ich teste erstmal Befi seins, dann seh ich ja ob meine Telemetrie geht.
Das sind Linuxgrundlagen. Ein & nach einem Befehl führt das ganze im Hintergrund aus. Befi benutzt einen USB-Seriell-Adapter, ich benutze die Raspi Schnittstelle. Daher der Unterschied.
tx ... -s 2 heißt dass ein TX mit 2 Streams gestartet wird, das ist bei mir auch so. p 0 ist der Video Stream, p 1 der Telemetriestream.
/rx -p $TELEM_PORT heißt im Endeffekt p 1 und /rx -p $PORT ist p 0.
Wenn du direkt vom Arduino ran gehst brauchst du keine Telemetrieinversion. Der Raspi hat das selbe TTL Level wie der Arduino. Nur die Frskyempfänger sind andersrum, daher brauchste bei denen die Inversion.
Schau dir mal dir Scripte von Befi an, die sind genauso:
https://bitbucket.org/befi/wifibroadcast_fpv_scripts/src
tx ... -s 2 heißt dass ein TX mit 2 Streams gestartet wird, das ist bei mir auch so. p 0 ist der Video Stream, p 1 der Telemetriestream.
/rx -p $TELEM_PORT heißt im Endeffekt p 1 und /rx -p $PORT ist p 0.
Wenn du direkt vom Arduino ran gehst brauchst du keine Telemetrieinversion. Der Raspi hat das selbe TTL Level wie der Arduino. Nur die Frskyempfänger sind andersrum, daher brauchste bei denen die Inversion.
Schau dir mal dir Scripte von Befi an, die sind genauso:
https://bitbucket.org/befi/wifibroadcast_fpv_scripts/src
- Status
