FPV Wifi Broadcasting HD Video - Thread zum Raspberry HD Videolink von Befi
- Themenstarter trailblazer
- Beginndatum
- Status
Ergebnisse zur Biteye FPV Cam:
H264 video latenz über USB: ~16ms bei 720p, ~30ms bei 1080p
Das ist h264 encode -> usb/rndis -> custom app -> hello_video (h264 decode) -> display - noch ohne wbc
-> Somit deutlich besser im vergleich zur raspi-cam bzw. allen sonstigen mir bekannten kombinationen. Insgesamt sollte man damit unter 100ms kommen.
Um an den h264 stream zu kommen muss man die cam über ein spezielles protokoll ansprechen. Die specs dafür kann man bei biteye anfordern. Die cam wird unter raspian direkt als usb/rndis device erkannt.
H264 video latenz über USB: ~16ms bei 720p, ~30ms bei 1080p
Das ist h264 encode -> usb/rndis -> custom app -> hello_video (h264 decode) -> display - noch ohne wbc
-> Somit deutlich besser im vergleich zur raspi-cam bzw. allen sonstigen mir bekannten kombinationen. Insgesamt sollte man damit unter 100ms kommen.
Um an den h264 stream zu kommen muss man die cam über ein spezielles protokoll ansprechen. Die specs dafür kann man bei biteye anfordern. Die cam wird unter raspian direkt als usb/rndis device erkannt.
ap103: Klingt echt interessant mit der Biteye Cam. Habe von RNDIS bis jetzt nur im Zusammenhang mit Netzwerkadaptern was gehört, wie sieht das genau aus mit dem Protokoll bzw dem ansprechen, könntest Du da mehr zu sagen? Kriegt man das halbwegs einfach aus der cam in die wifibroadcast tx applikation?
Im prinzip ist es eine relativ einfache tcp kommunikation. Es gibt vom hersteller eine windows app, jedoch noch nichts für linux.
Die cam scheint durch rndis als ip-device unter linux/raspian auf. Danach muss man einige tcp befehle über eine steuerverbindung über einen command port schicken und die antworten auswerten. Ist man damit erfolgreich kann man den video stream über einen eigenen port abgreifen. Dabei muss man aber aus mehreren packets die h264 frames assemblieren und dabei die header vom biteye protokoll entfernen. Etwas c kenntnisse schaden dabei sicher nicht
Auf jeden fall kann man das leicht direkt in den wbc code integrieren, damit spart man man zusätzlich die stdout/stdin kommunikation.
Die cam scheint durch rndis als ip-device unter linux/raspian auf. Danach muss man einige tcp befehle über eine steuerverbindung über einen command port schicken und die antworten auswerten. Ist man damit erfolgreich kann man den video stream über einen eigenen port abgreifen. Dabei muss man aber aus mehreren packets die h264 frames assemblieren und dabei die header vom biteye protokoll entfernen. Etwas c kenntnisse schaden dabei sicher nicht
Auf jeden fall kann man das leicht direkt in den wbc code integrieren, damit spart man man zusätzlich die stdout/stdin kommunikation.
Also bei mir kamen da andere Messungen raus, war aber noch mit der alten Firmware. Mit der neuen Firmware wird sie nur noch als USB-Speichergerät erkannt, da muss man das irgendwie anders machen....
Blöd, dass es keine zentrale Stelle gibt, wo die alle ihre Tools zur Verfügung stellen. Die verteilen die Links per Facebook, Forum usw... man weiß also nie wo die aktuellste Version zu finden ist...
Blöd, dass es keine zentrale Stelle gibt, wo die alle ihre Tools zur Verfügung stellen. Die verteilen die Links per Facebook, Forum usw... man weiß also nie wo die aktuellste Version zu finden ist...
Zuletzt bearbeitet:
Im prinzip ist es eine relativ einfache tcp kommunikation. Es gibt vom hersteller eine windows app, jedoch noch nichts für linux.
Die cam scheint durch rndis als ip-device unter linux/raspian auf. Danach muss man einige tcp befehle über eine steuerverbindung über einen command port schicken und die antworten auswerten. Ist man damit erfolgreich kann man den video stream über einen eigenen port abgreifen. Dabei muss man aber aus mehreren packets die h264 frames assemblieren und dabei die header vom biteye protokoll entfernen. Etwas c kenntnisse schaden dabei sicher nicht
Auf jeden fall kann man das leicht direkt in den wbc code integrieren, damit spart man man zusätzlich die stdout/stdin kommunikation.
Die cam scheint durch rndis als ip-device unter linux/raspian auf. Danach muss man einige tcp befehle über eine steuerverbindung über einen command port schicken und die antworten auswerten. Ist man damit erfolgreich kann man den video stream über einen eigenen port abgreifen. Dabei muss man aber aus mehreren packets die h264 frames assemblieren und dabei die header vom biteye protokoll entfernen. Etwas c kenntnisse schaden dabei sicher nicht
Auf jeden fall kann man das leicht direkt in den wbc code integrieren, damit spart man man zusätzlich die stdout/stdin kommunikation.
Ich frage mich deshalb wie Daten die über ein USB reinkommen, erst noch von der CPU verarbeitet werden müssen ('header vom biteye Protokoll entfernen ..') dann zu einer niedrigeren Latenz führen können.
Sagt mal, hat eigentlich mal jemand solche kleinen PCB Wifi Antennen an TX oder RX getestet?
www.aliexpress.com/item/5-pcs-lot-free-shipping-2-4G-5-8G-ipex-pcb-wifi-antenna/32493496704.html
http://www.aliexpress.com/item/WIFI...PCB-Antenna-built-in-With-IPX/2013539299.html
Lightbridge und Connex scheinen ja auch sowas zu nutzen, die größeren FrSky Empfänger auch.
Wie ist den eigentlich die Abstrahlung/Richtwirkung bei den Dingern, sprich wie montiert man die am besten?
www.aliexpress.com/item/5-pcs-lot-free-shipping-2-4G-5-8G-ipex-pcb-wifi-antenna/32493496704.html
http://www.aliexpress.com/item/WIFI...PCB-Antenna-built-in-With-IPX/2013539299.html
Lightbridge und Connex scheinen ja auch sowas zu nutzen, die größeren FrSky Empfänger auch.
Wie ist den eigentlich die Abstrahlung/Richtwirkung bei den Dingern, sprich wie montiert man die am besten?
Nachdem meine beiden Alfa AWUS052NH endlich angekommen sind und das System out of the box funktioniert hat, stellt sich mir aktuell die Frage, wie ich das System auf meinem Copter (4S 5200mAh) mit Strom versorge.
Mir sind dabei 3 Möglichkeiten eingefallen:
- zusätzlicher 2S LiPo und zusätzlicher 5V BEC
- an bereits vorhandenen 5V 3A BEC (der am Hauptakku hängt) anschließen und zusätzlich mit einem 1000μf - 1500μf ElKo puffern, um Spannungsschwankungen bei Vollgas vorzubeugen
- ohne zusätzlichen ElKo an den vorhandenen 5V 3A BEC hängen
Eigentlich würde mir die zweite Variante am meisten zusagen, da man hier nicht viel zusätzliches Gewicht bekommt.
Wie macht ihr das? Gibt es hier Empfehlungen?
Mir sind dabei 3 Möglichkeiten eingefallen:
- zusätzlicher 2S LiPo und zusätzlicher 5V BEC
- an bereits vorhandenen 5V 3A BEC (der am Hauptakku hängt) anschließen und zusätzlich mit einem 1000μf - 1500μf ElKo puffern, um Spannungsschwankungen bei Vollgas vorzubeugen
- ohne zusätzlichen ElKo an den vorhandenen 5V 3A BEC hängen
Eigentlich würde mir die zweite Variante am meisten zusagen, da man hier nicht viel zusätzliches Gewicht bekommt.
Wie macht ihr das? Gibt es hier Empfehlungen?
Hierzu gab es (zumindest für Frsky) eine Empfehlung: http://fpv-community.de/showthread....tennenposition&p=433372&viewfull=1#post433372
Danke Thomas!
Sagt leider nix in welche Richtung die Dinger nun genau Senden/Empfangen, nur das beide 90° sollen am Kopter.
BEC anzapfen oder kleines BEC verbauen würde ich sagen. Ich werde so eins mit nachgeschaltetem Elko verwenden, hab mit denen gute Erfahrungen gemacht. http://www.banggood.com/5V-12V-Adjustable-Voltage-Dual-BEC-Output-Board-Only-1g-p-1031884.html
Sagt leider nix in welche Richtung die Dinger nun genau Senden/Empfangen, nur das beide 90° sollen am Kopter.
BEC anzapfen oder kleines BEC verbauen würde ich sagen. Ich werde so eins mit nachgeschaltetem Elko verwenden, hab mit denen gute Erfahrungen gemacht. http://www.banggood.com/5V-12V-Adjustable-Voltage-Dual-BEC-Output-Board-Only-1g-p-1031884.html
Würde auch Variante 2 nehmen, vielleicht ggf zur Sicherheit noch ein grösseres BEC, je nachdem was sonst noch so dranhängt und wie stark die 3A übertrieben sind vom Hersteller.
Ansonsten gibts noch den Odroid-W, ca. Pi Zero Maße und eine integrierte Ladeschaltung für einen 1S lipo. Braucht man nur einen kleinen z.B. 200mAh lipo dranhängen und weiter nichts machen, der Akku wird immer voll gehalten und puffert bei Bedarf falls die Stromversorgung ausfällt oder schwankt.
Ansonsten gibts noch den Odroid-W, ca. Pi Zero Maße und eine integrierte Ladeschaltung für einen 1S lipo. Braucht man nur einen kleinen z.B. 200mAh lipo dranhängen und weiter nichts machen, der Akku wird immer voll gehalten und puffert bei Bedarf falls die Stromversorgung ausfällt oder schwankt.
Die Raspicam hat ca 60ms Latenz bei 48fps bis das h264 video aus Raspivid rasukommt. Das liegt an den 3 Frames die man für den Buffer braucht.
Aber wie gesagt... die Latenzzeiten da stimmen eh nicht. Die Biteye Cam braucht auch 3 Frames Buffer, die Latenz ist also mindestens genauso wie bei der Raspicam. Den einzigen Vorteil den man hat wäre, dass die Biteye Cam eine richtige Linse und einen besseren Sensor hat. Zumal 720p kein echtes 720p ist, sondern 648p oder so...
Aber wie gesagt... die Latenzzeiten da stimmen eh nicht. Die Biteye Cam braucht auch 3 Frames Buffer, die Latenz ist also mindestens genauso wie bei der Raspicam. Den einzigen Vorteil den man hat wäre, dass die Biteye Cam eine richtige Linse und einen besseren Sensor hat. Zumal 720p kein echtes 720p ist, sondern 648p oder so...
Zuletzt bearbeitet:
Du musst das voltage detection interface belegen, dann kommst du vom cardreader in den live-out mode. Ich hab dazu einfach einen PIN auf 5V gelegt, alternativ den lipo balancer port anschliessen.
Die windows app von biteye hat ca. 220ms latenz, dürfte also nicht wirklich effizient programmiert sein. Falls du das mit der latenz nicht glaubst kannst du
1) selbst den linux code schreiben, die beschreibung des private protocols hast du ja
2) bei gelegenheit meinen code testen damit du selbst messen kannst
btw ich hab den neuen batch der cam.
Die windows app von biteye hat ca. 220ms latenz, dürfte also nicht wirklich effizient programmiert sein. Falls du das mit der latenz nicht glaubst kannst du
1) selbst den linux code schreiben, die beschreibung des private protocols hast du ja
2) bei gelegenheit meinen code testen damit du selbst messen kannst
btw ich hab den neuen batch der cam.
Danke für den Link, der schaut gut aus! Wobei ich da fast meinen nehmen kann in Kombination mit einem ElKo
Es hängt zum Glück "nur" mein Naze32 Board und der Raspberry dran, sollte also deutlich unter 3A bleiben. Werde ich aber auch nochmal nachmessen.
Den raspberry hatte ich noch Zuhause liegen, daher wollte ich mir den Odroid-W sparen. Wobei das mit der Ladeschaltung echt praktisch ist. Wenns mit meiner Lösung nicht hin haut, hab ich schon mal eine alternative, danke!
Gibts für den ElKo eine Faustformel, welche Kapazität man etwa braucht?
Die 1000μf - 1500μf waren nur ein Schuss ins blaue von mir...
Es hängt zum Glück "nur" mein Naze32 Board und der Raspberry dran, sollte also deutlich unter 3A bleiben. Werde ich aber auch nochmal nachmessen.
Den raspberry hatte ich noch Zuhause liegen, daher wollte ich mir den Odroid-W sparen. Wobei das mit der Ladeschaltung echt praktisch ist. Wenns mit meiner Lösung nicht hin haut, hab ich schon mal eine alternative, danke!
Gibts für den ElKo eine Faustformel, welche Kapazität man etwa braucht?
Die 1000μf - 1500μf waren nur ein Schuss ins blaue von mir...
- Status
