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

Status
Nicht offen für weitere Antworten.
just_different

just_different

Erfahrener Benutzer
#341
#341
Ach noch was, warum verweigert mein RASPI das remote login?

Wenn ich mit dem Bitwise SSH Client versuche drauf zu gehen, bekomme ich die Meldung das der Login verweigert wurde.
Ich gehe doch mal vom Standard aus.. "pi/raspberry".. und auch der Port 23...auf der richtigen IP.

Ich bin über LAN-Kabel über einen Switch angeschlossen und habe den WIFI-Stick nicht drin.

Wo liegt da eventuell mein Denkfehler?
 
A

action

Erfahrener Benutzer
#342
#342
Kann einer sagen ob ich mit den sticks auch auf Kanal 14 funken kann? Habe dieses Frequenzbild


Und der einzige Kanal der nicht mit der dji Steuerung überlappt ist Kanal 14


Oder hat jemand eine dji Funke am laufen?

Habs nur mit der 5.8er getestet... Wäre schon praktisch dann könnte ich mir die Tests ersparen

Gruss
 
R

rodizio

Erfahrener Benutzer
#345
#345
http://yo3iiu.ro/blog/?p=1301
http://www.qsl.net/kb9mwr/projects/wireless/modify.html

Damit gehen dann recht viele Frequenzen.

Über 2500MHz würde ich nicht empfehlen, da ist LTE und soweit ich weiss finden die Mobilfunkanbieter das garnicht witzig wenn man die stört.

Probier' vielleicht mal 2487Mhz. Das ist zwar nicht mehr innerhalb der offiziellen WLAN-Kanäle, aber bei 20 MHz Kanalbandbreite ist man damit noch im ISM-Band unter 2500 Mhz, aber schon 25 MHz weit weg von Kanal 11 und 15MHz von Kanal 13. Da Kanal 13 in D selten genutzt wird, sollte man auf der Frequenz eigentlich fast überall recht alleine unterwegs sein und somit auch keine anderen WLANs stören.
 
A

action

Erfahrener Benutzer
#346
#346
rodizio hat gesagt.:
http://yo3iiu.ro/blog/?p=1301
http://www.qsl.net/kb9mwr/projects/wireless/modify.html

Damit gehen dann recht viele Frequenzen.

Über 2500MHz würde ich nicht empfehlen, da ist LTE und soweit ich weiss finden die Mobilfunkanbieter das garnicht witzig wenn man die stört.

Probier' vielleicht mal 2487Mhz. Das ist zwar nicht mehr innerhalb der offiziellen WLAN-Kanäle, aber bei 20 MHz Kanalbandbreite ist man damit noch im ISM-Band unter 2500 Mhz, aber schon 25 MHz weit weg von Kanal 11 und 15MHz von Kanal 13. Da Kanal 13 in D selten genutzt wird, sollte man auf der Frequenz eigentlich fast überall recht alleine unterwegs sein und somit auch keine anderen WLANs stören.
Zum Vergrößern anklicken....

Danke für den Tipp :)

Theoretisch liessen sich da die Funkeprobleme durch experimentieren mit bis zu 20Kanäle sicher eliminieren...

Aber mir gefällt jetzt für die schnelle Wahl die "JP" Option...

so wie ich es verstanden hab, auf tx und rx script die Zeile sudo iw .... "JP" Und alle 13 mit 14 ersetzen..? :p

Danke für eure Hilfe
 
C

cbl

Benutzer
#347
#347
@just_different, der Standard ssh-port ist 22. Wenns daran lag, gut. Sonst den raspi mal mit Tastatur an den Monitor hängen oder die SD-Karte auf nem Linuxrechner einhängen und unter /etc/ssh alles löschen und neu starten, dann wird ssh neu eingerichtet. Die Einstellungen vom Client evtl auch löschen, ssh merkt sich mit wem es in welchem Netzwerk unter welcher Adresse verbunden war und verweigert dann unter Umständen den Dienst wenn sich daran etwas ändert.

Natürlich kannst du auf Receiverseite auch nen Schleppi benutzen, allerdings würd ich von Kali zu Beginn abraten, das ist nicht besonders Einsteigerfreundlich und vor allem die Wifitreiber sind arg gepatcht. Das kann gut sein weil zum Teil Sachen funktionieren die der Standardtreiber nicht kann, das kann schlecht sein weil Bugs drinstecken oder sich die Benutzung von allem unterscheidet wozu du Anleitungen findest oder schlicht nichts mehr funktioniert weil die beim letzten Update Mist gebaut haben, als Anfänger bist du dann aufgeschmissen. Ich würde Debian oder Ubuntu bzw Mint empfehlen, dadurch lernst du auch das System auf dem raspi besser kennen.
 
just_different

just_different

Erfahrener Benutzer
#348
#348
@cbl: super, das hat geholfen.. es war Port 22!

Auch DEin andere Tipp war nicht schlecht, wenn ich da auch wieder was gelernt habe.
So: raspivid -ih -t 0 -w 1280 -h 720 -fps 48 -b 4500000 -n –ex backlight –awb horizon -g 60 -pf high -o - | tee /home/pi/wifibroadcast/videos/test_video.h264 | sudo /home/pi/wifibroadcast/tx -b 8 -r 2 wlan0

funktionierte es NICHT.. wegen der falschen Rechte.. und noch was anderes.

inzwischen funktioniert es SO bei mir.

raspivid -ih -t 0 -w 1280 -h 720 -fps 48 -b 4500000 -g 60 -pf high -o - | tee /home/video/flightvideo.h264 | sudo /home/pi/wifibroadcast/tx -b 8 -r 2 wlan0

Das Script läuft ja unter SUDO, und da muss ich natürlich auch in einem Verzeichnis, das SUDO erstellt hat, rein schreiben lassen.
Unter user PI darf das Script wohl nicht schreiben und hatte auch keine Datei angelegt mit obigem 1. Pfad, jetzt einfach unter home/video schon.

Wie man auch sieht, habe ich leider den Parameter " -n –ex backlight –awb horizon " weg lassen müssen. Denn sonst gab es auf RX-Seite nur "lost pakets", aber kein Bild.

Nebeneffekt, JETZT erst, bekomme ich durch das Tee-Komando AUCH ein Bild auf der TX-Seite zu sehen. Ohne TEE, gab es nur das durchzählen der pakete usw...

Da ich dann TX & RX auf je einem Bildschirm habe, kann ich die Latenz schon direkt sehen.
Ich vergleiche das mal mit dem steuern eins Karts/Rennwagens und einem normalen Straßenauto.
Das Bild der TX Cam, reagiert auf Bewegungen (im Zimmer) absolut sofort und unverzögert!
Dagegen auf dem RX, ist das Bild "entschleunigt", ruhiger bei Bewegung.

Eine Zeitmessung kann ich nur per Handy-Uhr machen, da mein RX über den Laptop per HDMI-IN läuft und ich dann keine Windows Uhr sehen könnte. Ein Fenster kann ich davon bisher noch nicht machen.

Aber dennoch.... hier mal das Ergenbis der Latenz: ca. 140ms, wenn ich richtig gerechnet habe.
 

Anhänge

Zuletzt bearbeitet:
just_different

just_different

Erfahrener Benutzer
#349
#349
mein erstes, auf dem TX gespeichertes Video:

Mit XMediaRecode, direkt vom gespeicherten File (nix umbenennen oder so), in MP4 gespeichert.
Ist gerade neu raus gekommen und direkt von der offiziellen WEB-Site.

[video]http://hfb.sinndorfer.square7.de/test-video_TX-Pi_H264.mp4[/video]

Nu gehts noch dran, das auf eine Stick zu speichern, den ich leicht unter Windows nutzen kann.
Also NTFS oder FAT32 formatiert.
Wobei, bei NTFS, müßte erst noch das Paket zum schreiben unter Linux installiert werden.

Schön wäre es auch noch, wenn ich den Alfa-Stick, neben dem TP-Link mit an laufen bekommen könnte. der hat zwar noch keine externe Antenne... aber dennoch hätte ich dann schon mal Diversity.
Ich denke, da muss ich im Bootscript was ändern...und im .sh

Ach, ist es normal, dass beim starten Warnmeldungen kommen und ein "Dirtybit" gesetzt wird?
 
Zuletzt bearbeitet:
just_different

just_different

Erfahrener Benutzer
#350
#350
Speichern auf einem USB-Stick, funktioniert und ist im Startscript mit eingebunden.

Python-Script für den Taster ist erledigt,
nur der 10K Widerstand fehlt noch und der Taster... dann passt auch das.

Denn, wenn der PI nicht korrket runter gefahren wird, oder zumindest ein Sync auf den Stick gemacht wird, ist die Videodatei unbrauchbar.
Also einfach Akku ziehen ist nicht und immer ne Tastatur mit schleppen..nee.

Anbei übrigens ein bild von der Stromversorgung über ein 5V UBEC. mit Absicht NICHT am GPIO angeschlossen, weil da nämlich die Sicherung (gegen Kurzschlüsse usw.) des PI´s überbrückt wäre.
 

Anhänge

S

Schalonsus

Erfahrener Benutzer
#351
#351
Hättest die Stromversorgung auch an die PP Pins auf der Rückseite löten können, dafür sind sie da. Sitzen auch vor der Sicherung ;)
PP1 und PP2 sind +5V und PP3 ist GND

Edit: seh grad bei dir sind irgendwie keine, was hast du für ein PI Modell?
 
Zuletzt bearbeitet:
just_different

just_different

Erfahrener Benutzer
#352
#352
Ich habe das normale B Board... also kein B+ und kein A oder A+ und auch kein P2B..zumindest auf dem Copter.

Den B+ habe ich am RX.
 
just_different

just_different

Erfahrener Benutzer
#353
#353
uups.. gerade noch mal ein Latenztest gemacht, mit der Einstellung, dass das Video auf dem , per USB-Stick eingebundenen,
zusätzlichen Speicherstick liegt.

WOW.. 7sec. Latenz: Das war nix und wieder zurück.

Na zumindest habe ich mehr Speicher auf meiner SD-Card frei gegeben... und mal schauen, wie ich das dann mache mit dem einfachen übertragen auf den Laptop.
Vielleicht Cross-Kabel und per SSH-Client-SFTP? Das geht zumindest auch auf dem Feld einfach.
Dann muss ich noch schauen, wie die IP´s ohne DHCP sind mit Cross-Kabel oder welche festlegen.

Oder den Rest der 16GB-SD-Card als FAT32 und per GPIO-Taster & Python, von der Linux auf die FAT32-Partition kopieren lassen, Vielleicht sogar noch mit Uhrzeit im Namen versehen? oder geht das schon bei der Aufnahme?
Wie macht Ihr das, wenn ihr fliegt und zwischendurch Akku wechselt? Beim Neustart, wird doch dann die alte Datei überschrieben.
 
M

moritzz06

Erfahrener Benutzer
#355
#355
Ich habe gestern versucht den France Mode zu testen, leider ohne Erfolg.. Immer noch viele Störungen, ab ca. 150m wird es unfliegbar.
Auch Kanal 14 wollte ich testen, aber das scheint nicht zu funktionieren.. Habe auf beiden Seiten iw reg set JP eingegeben und den Kanal auf 14 gestellt und dann blinken aber die WLAN Sticks nicht mehr.
Muss ich da noch was beachten?

Sehr interessant die Sticks unterhalb vom ISM Band laufen zu lassen, im 23xxMhz Bereich. Leider hört sich das sehr kompliziert an, würde dann aber sämtliche Störungsprobleme auch mit anderen Piloten beheben.
Versucht sich jemand daran die Treiber zu ändern und den Kernel neu zu kompilieren?
 
just_different

just_different

Erfahrener Benutzer
#356
#356
RonaldoFPV, Du sprichst in der Vergangenheitsform.. "wurde im Skript"....(welches Script? runwifibroadcast.sh?)

Denn inzwischen habe ich das stehen | tee /home/video/flight_$date.h264 | ....
und die Datei heißt "flight_.h264"

Wie sieht denn Deine Datei / Dein Script aus... mal so kpl.?
Welche Latenzzeiten hast Du denn so, mit welchem Setup?
 
ronaldofpv

ronaldofpv

Erfahrener Benutzer
#357
#357
Aktuell sieht es bei mir so aus:

#!/bin/bash # rx script #adapt these to your needs CHANNEL="13" NICS=`ls /sys/class/net | grep wlan` SAVE_PATH="/media/usb0/video" WBC_PATH="/home/pi/wifibroadcast" DISPLAY_PROGRAM="/opt/vc/src/hello_pi/hello_video/hello_video.bin" ################################## #change these only if you know what you are doing (and remember to change them on both sides) RETRANSMISSION_BLOCK_SIZE=8 PORT=0 ################################## function prepare_nic { echo "updating wifi ($1, $2)" ifconfig $1 down iw dev $1 set monitor otherbss fcsfail ifconfig $1 up iwconfig $1 channel $2 } ################################# SCRIPT START ####################### # Make sure only root can run our script if [[ $EUID -ne 0 ]]; then echo "This script must be run as root" 1>&2 exit 1 fi #prepare NICS for NIC in $NICS do prepare_nic $NIC $CHANNEL done if [ -d "$SAVE_PATH" ]; then echo "Starting with recording" FILE_NAME=$SAVE_PATH/`ls $SAVE_PATH | wc -l`.rawvid $WBC_PATH/rx -p $PORT -b $RETRANSMISSION_BLOCK_SIZE $NICS | tee $FILE_NAME | $DISPLAY_PROGRAM else echo "Starting without recording" $WBC_PATH/rx -p $PORT -b $RETRANSMISSION_BLOCK_SIZE $NICS | $DISPLAY_PROGRAM fi

Arbeite aber mit einem anderen Image da ich alles auf die original rx und tx Seite von befi umgebaut habe.

Aktueller Stand :
1. Aufnahme auf rx wenn usb angesteckt
2. Automatische Auswahl wieviele tp link angesteckt und initialisiert werden müssen
3. Osd für naza v1 und v2

Gruß Ronald
 
just_different

just_different

Erfahrener Benutzer
#358
#358
Ich habe mal folgende Aufbau gemacht:
Links den TX per HDMI an einen Monitor
Stoppuhr
Rechts den RX per HDMI an einen Monitor

alles zusammen auf einem Bild.. bzw. Serienfotos... interessant.
Schon 60ms delay, von Echtzeit Stopuhr, bis Bild auf dem TX-Monitor zu sehen ist,
Dann noch mal weitere 110-120ms beim RX.

hat jemand ähnliche Erfahrungen gemacht?

Warum wird eigentlich beim TX, bei Verwendung vom TEE-Command, das Bild auf dem Monitor mit ausgegeben?
Ist das eventuell eine Komponente, bei der man Zeit sparen könnte?
 

Anhänge

just_different

just_different

Erfahrener Benutzer
#359
#359
@ronaldoFPV . . ARG.. haben wollen... speziell auch das mit dem OSD.

Wie hast Du das gelöst? per Arduino oder direkt mit dem RASPI?

hey.. das hört sich ja mehr als super an.

Und auf welche Zeiten kommst Du so an ms?


Was muss man denn noch so umbauen?
 
A

action

Erfahrener Benutzer
#360
#360
Nice, das kommt ja richtig voran ;-)

@ronaldofpv; was wäre bei dir z.B zu ändern damit die Sticks auf 14 funken?

Habe auch schon die Region auf JP versucht auf beiden Seiten, und alle 13 mit 14 ersetzt. lief leider auch nicht.

Gruss

PS: Welches Format muss der Stick haben?
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten