Wurde bereits gepostet: http://fpv-community.de/showthread....ung-Telemetrie&p=714579&viewfull=1#post714579
Low Cost HD-Video Übertragung + Telemetrie
- Themenstarter Lonestar78
- Beginndatum
- Status
hi,
kann mir jemand sagen, wie ich die autostart scripte direkt in der comandline vom raspi installieren kann?
https://bitbucket.org/befi/wifibroa...f2421c01a1a7c52332e7e09b344b7b2622?at=default
ich bin in linux nicht so fit aber des muss doch irgendwie möglich sein?
habs doch selbst hinbekommen:
hg clone https://bitbucket.org/befi/wifibroadcast_fpv_scripts/src/497917f2421c?
cd 497917f2421c
cd init.d
sudo cp wbctxd /etc/init.d
sudo update-rc.d wbctxd start
cd
mkdir wifibroadcast_fpv_scripts
cd
cd 497917f2421c
sudo cp tx.sh /wifibroadcast_fpv_scripts
sudo reboot
fertig
für rx einfach rx.sh auf tx.sh und wbctxd auf wbcrxd ändern...
danke
kann mir jemand sagen, wie ich die autostart scripte direkt in der comandline vom raspi installieren kann?
https://bitbucket.org/befi/wifibroa...f2421c01a1a7c52332e7e09b344b7b2622?at=default
ich bin in linux nicht so fit aber des muss doch irgendwie möglich sein?
habs doch selbst hinbekommen:
hg clone https://bitbucket.org/befi/wifibroadcast_fpv_scripts/src/497917f2421c?
cd 497917f2421c
cd init.d
sudo cp wbctxd /etc/init.d
sudo update-rc.d wbctxd start
cd
mkdir wifibroadcast_fpv_scripts
cd
cd 497917f2421c
sudo cp tx.sh /wifibroadcast_fpv_scripts
sudo reboot
fertig
für rx einfach rx.sh auf tx.sh und wbctxd auf wbcrxd ändern...
danke
Zuletzt bearbeitet:
Ich hatte einen eigenen Thread für dieses Projekt (Wifi Broadcast) aufgemacht, vllt. deinen Post hierher kopieren/verschieben:
http://fpv-community.de/showthread....eo-Thread-zum-Raspberry-HD-Videolink-fon-Befi
http://fpv-community.de/showthread....eo-Thread-zum-Raspberry-HD-Videolink-fon-Befi
Mir ist noch etwas aufgefallen: Leider ist das iso image zwar sogar etwas weniger als "echte" 8 gb groß, trotzdem passte es auf 2 meiner 3 sdhc karten nicht drauf- zwar nur um ein paar kb aber das ändert nix. Liegt daran dass die Hersteller sich dabei immer etwas spuelraum nehmen.
Vlt kann sich ja jemand die mühe machen und ein image mit pspw. einer 2 oder 4gb karte erstellen.
Ein "expand file system" ist leicht zu finden, ein "shrink file system" mir leider unbekannt.
Und ausserdem,wozu braucht es die 8GB ?
Vlt kann sich ja jemand die mühe machen und ein image mit pspw. einer 2 oder 4gb karte erstellen.
Ein "expand file system" ist leicht zu finden, ein "shrink file system" mir leider unbekannt.
Und ausserdem,wozu braucht es die 8GB ?
Ein Frage von mir.. bezüglich Sticks... und auch bezüglich Windows.
Taugt dieser Stick was?
http://www.ebay.de/itm/ALFA-Network...72?pt=LH_DefaultDomain_77&hash=item4aea4cc790
Denn mit 5GHz sollte er die 2,4GHz steuer frequenz doch ganz sicher nicht stören... und ist dann auch noch sau schnell und gleich TX-Diversity.
2. Irgendwo hier im Thread (finde es gerade nicht wieder), hatte mal jemand was von einer Windows-RX-Variante geschrieben, oder zumindest den Versuch dazu.
Existiert dazu ein Programm/Treiber oder was auch immer benötigt wird?
Denn da ich glücklicherweise eine Alienware Laptop habe, der auch einen HDMI-IN besitzt und USB 3.0, wäre mir das 17,4" HQ Display doch viel lieber als ein 7"... *smile*
Wenn es also was für Windows 7 gäbe.. wäre das superklasse... ansonsten halt über RASPI & HDMI, zumal ich dann per USB den RX-raspi mit Strom versorgen könnte. Der Laptop hält rund 2Std.. ohne selbst BT&WIFI an zu haben..usw.
Das Projekt.. hört sich SUUper an.. und heute ist mein 2. PI (B+)gekommen (TX B) und Images sind auch gerade fertig geladen.
Taugt dieser Stick was?
http://www.ebay.de/itm/ALFA-Network...72?pt=LH_DefaultDomain_77&hash=item4aea4cc790
Denn mit 5GHz sollte er die 2,4GHz steuer frequenz doch ganz sicher nicht stören... und ist dann auch noch sau schnell und gleich TX-Diversity.
2. Irgendwo hier im Thread (finde es gerade nicht wieder), hatte mal jemand was von einer Windows-RX-Variante geschrieben, oder zumindest den Versuch dazu.
Existiert dazu ein Programm/Treiber oder was auch immer benötigt wird?
Denn da ich glücklicherweise eine Alienware Laptop habe, der auch einen HDMI-IN besitzt und USB 3.0, wäre mir das 17,4" HQ Display doch viel lieber als ein 7"... *smile*
Wenn es also was für Windows 7 gäbe.. wäre das superklasse... ansonsten halt über RASPI & HDMI, zumal ich dann per USB den RX-raspi mit Strom versorgen könnte. Der Laptop hält rund 2Std.. ohne selbst BT&WIFI an zu haben..usw.
Das Projekt.. hört sich SUUper an.. und heute ist mein 2. PI (B+)gekommen (TX B) und Images sind auch gerade fertig geladen.
Bezüglich Windows:
Ich werde sobald mein system dann mal läuft ;-) versuchen die Daten via LAN vom RpI auf ein Windows Gerät zu bekommen. Dann sollte man problemlos jedes Gerät brauchen können das man hat, vorausgesetzt man hat genügend Leistung etc.
5Ghz soll scheinbar in DE aus der Luft illegal sein - zudem gibt es eben halt noch keine gepatchte Firmware. Aber sowas wird sicher auch noch kommen.
Bei mir wird es wohl so weitergehen, dass ich ein kleines Programm schreibe die die RC Daten via Wlan zum SenderPI schicken wird, und da via Arduino wieder in PPM Signale umwandelt. Nachteil daran ist sicherlich, dass nun auch der RX senden muss und man somit wieder keine extremen Antennen nutzen kann (legal). Dann kommt man aber um 2.4Ghz herum und sollte ruhe haben. Das wäre dann so quasi eine Lightbridge.
Bis dahin dauert es aber sicherlich noch ewig, da ich einfach kaum zeit finde für solche basteleien und es wird wohl jemand anderes eine viiiel bessere Lösung präsentieren
Ich werde sobald mein system dann mal läuft ;-) versuchen die Daten via LAN vom RpI auf ein Windows Gerät zu bekommen. Dann sollte man problemlos jedes Gerät brauchen können das man hat, vorausgesetzt man hat genügend Leistung etc.
5Ghz soll scheinbar in DE aus der Luft illegal sein - zudem gibt es eben halt noch keine gepatchte Firmware. Aber sowas wird sicher auch noch kommen.
Bei mir wird es wohl so weitergehen, dass ich ein kleines Programm schreibe die die RC Daten via Wlan zum SenderPI schicken wird, und da via Arduino wieder in PPM Signale umwandelt. Nachteil daran ist sicherlich, dass nun auch der RX senden muss und man somit wieder keine extremen Antennen nutzen kann (legal). Dann kommt man aber um 2.4Ghz herum und sollte ruhe haben. Das wäre dann so quasi eine Lightbridge.
Bis dahin dauert es aber sicherlich noch ewig, da ich einfach kaum zeit finde für solche basteleien und es wird wohl jemand anderes eine viiiel bessere Lösung präsentieren
Hallo,
Ich habe mir mal die mühe gemacht und ein paar tests zu den latenzzeiten gemacht.
Teil 1) Setup:
-Raspberry Pi mit Raspbian, Gstreamer selbst installiert ( wie in post 10 beschrieben)
-4Jahre alter laptop mit i3, 2*2.4 ghz display 720p und refresh rate 59fps,
Betriebssystem LINUX MINT
-direkt über lan (ohne router,feste ip) verbunden, mind. 40mbit/s möglich
Teil 2) wie wurde gemessen:
Raspicam filmt stoppuhr (vom handy,refresh rate 59fps) ab,das übertragene bild wird am laptop angezeigt. Ein foto von uhr+uhr auf dem laptop ermöglicht messungen. Nicht die "kaskaden bilden" lösung gewählt; jeweils etwa 5messungen pro einstellung
Teil 3) Ergebnisse:
1.1) 720p, 49fps, pf high,Bitrate variabel
1Mbit/s ~110ms
2Mbit/s~110 ms
4Mbit/s~120ms
5Mbit/s~120ms
7Mbit/s stark schwankend 100ms bis 9SEKUNDEN
1.2) 49fps, 3Mbit/s , variable Auflösung
720p ~90-170ms
600*480 ~ 90-140 ms
1.3) var. Fps, 3Mbit/s mit 640*480 und 720p
640*480 25fps 160ms
640*480 35fps 160ms
640*480 60fps 100ms
640*480 90fps 90ms ZIEMLICH KONSTANT
720P 25fps 170ms
35fps 150ms
49fps 130ms
1.4) variable intra refresh period 1280*720 3Mbit/s pf=high
-g =1 1.5Sekunden
-g=10 90ms-170ms
-g=100 stark schwanken 90ms-170ms
1.5) 720p pf high und pf baseline
720p 25fps baseline 170ms high 170ms
720p 49fps baseline 80-170ms high 90-170ms
#1
Ich habe mir mal die mühe gemacht und ein paar tests zu den latenzzeiten gemacht.
Teil 1) Setup:
-Raspberry Pi mit Raspbian, Gstreamer selbst installiert ( wie in post 10 beschrieben)
-4Jahre alter laptop mit i3, 2*2.4 ghz display 720p und refresh rate 59fps,
Betriebssystem LINUX MINT
-direkt über lan (ohne router,feste ip) verbunden, mind. 40mbit/s möglich
Teil 2) wie wurde gemessen:
Raspicam filmt stoppuhr (vom handy,refresh rate 59fps) ab,das übertragene bild wird am laptop angezeigt. Ein foto von uhr+uhr auf dem laptop ermöglicht messungen. Nicht die "kaskaden bilden" lösung gewählt; jeweils etwa 5messungen pro einstellung
Teil 3) Ergebnisse:
1.1) 720p, 49fps, pf high,Bitrate variabel
1Mbit/s ~110ms
2Mbit/s~110 ms
4Mbit/s~120ms
5Mbit/s~120ms
7Mbit/s stark schwankend 100ms bis 9SEKUNDEN
1.2) 49fps, 3Mbit/s , variable Auflösung
720p ~90-170ms
600*480 ~ 90-140 ms
1.3) var. Fps, 3Mbit/s mit 640*480 und 720p
640*480 25fps 160ms
640*480 35fps 160ms
640*480 60fps 100ms
640*480 90fps 90ms ZIEMLICH KONSTANT
720P 25fps 170ms
35fps 150ms
49fps 130ms
1.4) variable intra refresh period 1280*720 3Mbit/s pf=high
-g =1 1.5Sekunden
-g=10 90ms-170ms
-g=100 stark schwanken 90ms-170ms
1.5) 720p pf high und pf baseline
720p 25fps baseline 170ms high 170ms
720p 49fps baseline 80-170ms high 90-170ms
#1
#2
Zu 1.1) bestätigte die Meinung dass beim raspberry (nicht lan) ein max. Punkt erreicht werden kann (~5Mbit/s ab dem ebendieser überfordert ist.)
Es kann aber auch an dem empfangs-pc liegen; dies ist eher unwahrscheinlich da das phänomen schon mal in den posts beschrieben wurde.
Zu 1.2) die auflösung hat (fast) keinen effekt auf die latenzzeit
Zu 1.3) aber die fps. Höhere fps -> geringere latency . erklärung folgt.
Zu 1.4) und 1.5) anders als erhofft zeigten die verschiedenen profile keine verbesserung, mit der intra refresh period lässt sich noch spielen
Zu 1.1) bestätigte die Meinung dass beim raspberry (nicht lan) ein max. Punkt erreicht werden kann (~5Mbit/s ab dem ebendieser überfordert ist.)
Es kann aber auch an dem empfangs-pc liegen; dies ist eher unwahrscheinlich da das phänomen schon mal in den posts beschrieben wurde.
Zu 1.2) die auflösung hat (fast) keinen effekt auf die latenzzeit
Zu 1.3) aber die fps. Höhere fps -> geringere latency . erklärung folgt.
Zu 1.4) und 1.5) anders als erhofft zeigten die verschiedenen profile keine verbesserung, mit der intra refresh period lässt sich noch spielen
#3 etwas zu dem verwendeten videostandart (H.264)
Im gegensatz zu bspw. mjpeg ( wo jedes frame einzeln als jpeg gesendet wird) ist h.264 deutlich komplizierter.
Ich gehe mal auf das für uns wichtige ein:
Es gibt 3 framearten. I-frames,P-frames und B-frames.
I : am wenigsten komprimiert,braucht keine anderen frames um decodiert zu werden.
P : benutzt vorherige Frames ; wenn sich bespielsweise eine hand nur bewegt wird nur die neue position der Hand übertragen ,nicht nochmal unser ganzes Bild
B : hier kommt der haken ins spiel: benutzt SOWOHL vorherige als auch NACHFOLGENDE frames. Sinnvol bei videos ( wo die "zukunft" schon geschrieben steht) bei uns aber ein problem - um ein B frame zu encodieren müssen wir buffern es zu decodieren müssen wir auf die "folgenden" warten
Jetzt zeigen aber meine tests etwas komisches : das profil baseline bringt uns keine Vorteile - obwohl es (nach definition) keine B-frames hat und somit eigtl. Weniger latenzzeiten haben sollte.
Was ich daraus folgere: wie h.264 jeweils implementiert wird ist von den herstellern abhängig. Scheinbar produziert der raspberry auch in high keine (oder wenige) B-frames. Muss mal schauen wie ich das überprüfen kann.
Weiter geht's :
hier ist der Sourcecode zur raspi cam
https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/raspicam/RaspiVid.c
Da steht ganz am anfang "define Videos output num 3 " - wenn das die Anzahl der frames ist die der raspi buffert (MUSS nicht sein) wäre erklärt weshalb es (fast) keine b-frames gibt und unser Latenzzeit-killer gefunden.
Daneben steht noch min. 2 man könnte also das ganze ändern und neu kompilieren.
Kenn mich zwar mit solch hardware-nahen Sachen nicht richtig aus vlt. Bekomm ich's aber doch hin.
Uff das war's wenn der fehlerteufel zugeschlagen hat bitte verbessern !
Lg
Constantin
Im gegensatz zu bspw. mjpeg ( wo jedes frame einzeln als jpeg gesendet wird) ist h.264 deutlich komplizierter.
Ich gehe mal auf das für uns wichtige ein:
Es gibt 3 framearten. I-frames,P-frames und B-frames.
I : am wenigsten komprimiert,braucht keine anderen frames um decodiert zu werden.
P : benutzt vorherige Frames ; wenn sich bespielsweise eine hand nur bewegt wird nur die neue position der Hand übertragen ,nicht nochmal unser ganzes Bild
B : hier kommt der haken ins spiel: benutzt SOWOHL vorherige als auch NACHFOLGENDE frames. Sinnvol bei videos ( wo die "zukunft" schon geschrieben steht)
bei uns aber ein problem - um ein B frame zu encodieren müssen wir buffern es zu decodieren müssen wir auf die "folgenden" wartenJetzt zeigen aber meine tests etwas komisches : das profil baseline bringt uns keine Vorteile - obwohl es (nach definition) keine B-frames hat und somit eigtl. Weniger latenzzeiten haben sollte.
Was ich daraus folgere: wie h.264 jeweils implementiert wird ist von den herstellern abhängig. Scheinbar produziert der raspberry auch in high keine (oder wenige) B-frames. Muss mal schauen wie ich das überprüfen kann.
Weiter geht's :
hier ist der Sourcecode zur raspi cam
https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/raspicam/RaspiVid.c
Da steht ganz am anfang "define Videos output num 3 " - wenn das die Anzahl der frames ist die der raspi buffert (MUSS nicht sein) wäre erklärt weshalb es (fast) keine b-frames gibt und unser Latenzzeit-killer gefunden.
Daneben steht noch min. 2 man könnte also das ganze ändern und neu kompilieren.
Kenn mich zwar mit solch hardware-nahen Sachen nicht richtig aus vlt. Bekomm ich's aber doch hin.
Uff das war's wenn der fehlerteufel zugeschlagen hat bitte verbessern !
Lg
Constantin
- Status
