FPV Wifi Broadcasting HD Video - Thread zum Raspberry HD Videolink von Befi
- Themenstarter trailblazer
- Beginndatum
- Status
Constantin, wenn Du dir diese Thread von Anfang an genauer anschaust, dann wirst Du wissen, das es nicht daran liegt, das dies unerwünscht ist, sondern dass es schon mal eingehend beschrieben wurde, mit allen gesetzlichen Aspekten, Hinweis auf Vorschriften / Versicherung und Einschränkungen für Deutschland und auch Östereich.
Wenn Du das gelesen hättest, würdest Du diese Behauptung nicht so aufstellen. Außerdem hatte ich selbst ja in der Diskussion mit Dir, auch darauf hingewiesen. Also was soll das jetzt?
Worauf willst Du hinaus?
Wenn Du das gelesen hättest, würdest Du diese Behauptung nicht so aufstellen. Außerdem hatte ich selbst ja in der Diskussion mit Dir, auch darauf hingewiesen. Also was soll das jetzt?
Worauf willst Du hinaus?
Hallo zusammen,
ich habe vor einiger Zeit den unten beschrieben Effekt feststellen müssen. Ich bekomme das einfach nicht gelöst. Hat jemand eine Idee? Gibt es z.B. eine einfache Möglichkeit das genutzte Spektrum der Funke zu prüfen? Ich will nicht einfach so loslaufen und eine neue Funke "Auf gut Glück" kaufen. Hat jemand etwas ähnliches beobachtet? Wie sind Eure Error-Rates? Welche Funke benutzt Ihr?
Danke!
########################################################
ich habe vor einiger Zeit den unten beschrieben Effekt feststellen müssen. Ich bekomme das einfach nicht gelöst. Hat jemand eine Idee? Gibt es z.B. eine einfache Möglichkeit das genutzte Spektrum der Funke zu prüfen? Ich will nicht einfach so loslaufen und eine neue Funke "Auf gut Glück" kaufen. Hat jemand etwas ähnliches beobachtet? Wie sind Eure Error-Rates? Welche Funke benutzt Ihr?
Danke!
########################################################
Ich beobachte momentan ein sehr komisches Verhalten: Egal welchen Kanal ich wähle (-14,-13,..1,2,...,13), in Kombination mit meiner Turnigy-i6 mit dem billo ib6a Empfänger, bekomme ich laut Funke 30-50% Error-Rate - Und die Reichweite des Video Singnals ist auch dementsprechend kurz (ca. 30Meter). Der Raspberry wird momentan über den Kopter mit Strom versorgt. Kann das sein, kann die Turnigy das Spektrum so breit nutzt? Sollte ja nicht so sein 
)
viele Grüße
Daniel
) viele Grüße
Daniel
Zuletzt bearbeitet:
Hi moritzz06,
ja, habe ich bereits versucht. Als TX habe ich eine RPI, auf Empfängerseite einen UBUNTU PC. Ich bekomme auch nur ein Videosignal wenn beide Kanäle übereinstimmen - auch im negativen Bereich also z.B. -3 & -3; -3 und +3 harmoniert also nicht.
Zur Sicherheit habe ich auch die Stromversorgung des PI mal von der des Kopters getrennt -> selbes Ergebnis.
Die Verbindung bricht immer genau dann ein, wenn der Wlan-Stick zu senden beginnt (also die Grüne LED blinkt). Der Error ist praktisch auf jedem Kanal zwischen -13 und +13 gleich groß. Kann mir kaum Vorstellen, dass die Turnigy i6 auf 2,3 -2,4x GHz sendet... ??
PS: Ohne Videoübertragung liegt der Fehler bei ca. 1-3%
lg
ja, habe ich bereits versucht. Als TX habe ich eine RPI, auf Empfängerseite einen UBUNTU PC. Ich bekomme auch nur ein Videosignal wenn beide Kanäle übereinstimmen - auch im negativen Bereich also z.B. -3 & -3; -3 und +3 harmoniert also nicht.
Zur Sicherheit habe ich auch die Stromversorgung des PI mal von der des Kopters getrennt -> selbes Ergebnis.
Die Verbindung bricht immer genau dann ein, wenn der Wlan-Stick zu senden beginnt (also die Grüne LED blinkt). Der Error ist praktisch auf jedem Kanal zwischen -13 und +13 gleich groß. Kann mir kaum Vorstellen, dass die Turnigy i6 auf 2,3 -2,4x GHz sendet... ??
PS: Ohne Videoübertragung liegt der Fehler bei ca. 1-3%
lg
Zuletzt bearbeitet:
@Schluff81:
hast Du zufällig am TX einen Monitor dran, oder kannst einen mal ran machen?
Könnte es sein, dass oben Rechts ein Bunter Würfel auftaucht?
Dann wäre es die Spannungsversorgung. Der Pi ist da nicht sonderlich robust, und 1000-2000mW wollen Ihren Strom haben.
Wenn ja, dann am Stick, die USB-versorgung auf der Plusseite unterbrechen, und per UBEC 5V, den Stick getrennt versorgen.
Ich würde dazu raten, z.B. eine JST-Stecker zu nutzen, dann kannst Du immer noch mal abklemmen und auch anderweitig Offline versorgen.
Ich denke, ich werde das bei meinem Raspi B auch machen, denn der hat in etwa das gleiche verhalten, ist nicht sonderlich stabil.
Der PI B+ ist da besser.
hast Du zufällig am TX einen Monitor dran, oder kannst einen mal ran machen?
Könnte es sein, dass oben Rechts ein Bunter Würfel auftaucht?
Dann wäre es die Spannungsversorgung. Der Pi ist da nicht sonderlich robust, und 1000-2000mW wollen Ihren Strom haben.
Wenn ja, dann am Stick, die USB-versorgung auf der Plusseite unterbrechen, und per UBEC 5V, den Stick getrennt versorgen.
Ich würde dazu raten, z.B. eine JST-Stecker zu nutzen, dann kannst Du immer noch mal abklemmen und auch anderweitig Offline versorgen.
Ich denke, ich werde das bei meinem Raspi B auch machen, denn der hat in etwa das gleiche verhalten, ist nicht sonderlich stabil.
Der PI B+ ist da besser.
Hey just_different,
gehe bereits über ein 3A UBEC via JST dran... hatte ich auch schon im Verdacht gehabt.
Hier habe ich eine mögliche Erklärung bekommen, wobei ich mich dann Frage warum alle anderen solche Probleme nicht haben ... http://fpv-community.de/showthread.php?68728-Frequenzbereich-Turnigy-i6-wirklich-2-4-2-4X
Darf ich fragen, welche Funke nutzt Du?
lg
gehe bereits über ein 3A UBEC via JST dran... hatte ich auch schon im Verdacht gehabt.
Hier habe ich eine mögliche Erklärung bekommen, wobei ich mich dann Frage warum alle anderen solche Probleme nicht haben ... http://fpv-community.de/showthread.php?68728-Frequenzbereich-Turnigy-i6-wirklich-2-4-2-4X
Darf ich fragen, welche Funke nutzt Du?
lg
Zuletzt bearbeitet:
Ich nutze eine Graupner und habe Dir im anderen Thread ausführlicher geantwortet.
Mal ne Frage, Du schreibst mit UBEC 3A und JST.. Du meinst am PI selbst, also SEINE Stromversorgung?
Denn ich habe gerade festgestellt, dass der PI, der die USB-Slot für den Stick, mit Strom versorgt in die Unterversorgung kommt (bunter Würfel), wenn der Alpha senden soll.
Dann findet das Script auch kein WLAN-Device mehr.
Ich werde im ersten Step also versuchen, die Stromversorgung für die USB-Buchsen am PI, VOR den Spannugs-Chip zu legen. Der wird nämlich auch etwas warm...
Das erklärt für mich nämlich auch das Verhalten im Live-Test.
Wenn ich da nämlich schön ruhig durch die Gegend gehovert bin, dann sah es recht gut aus.
Aber schon ein YAW+Roll-Kurvenflug reichte, um das Bild schlechter werden zu lassen, wenn es etwas schneller war. Also wenn der Copter mehr Leistung gezogen hat.
OK, ein 30/35A-Burst ESC, und ein 25+ Lipo passen nicht soo wirklich zusammen, aber kommt später dran.
Mal ne Frage, Du schreibst mit UBEC 3A und JST.. Du meinst am PI selbst, also SEINE Stromversorgung?
Denn ich habe gerade festgestellt, dass der PI, der die USB-Slot für den Stick, mit Strom versorgt in die Unterversorgung kommt (bunter Würfel), wenn der Alpha senden soll.
Dann findet das Script auch kein WLAN-Device mehr.
Ich werde im ersten Step also versuchen, die Stromversorgung für die USB-Buchsen am PI, VOR den Spannugs-Chip zu legen. Der wird nämlich auch etwas warm...
Das erklärt für mich nämlich auch das Verhalten im Live-Test.
Wenn ich da nämlich schön ruhig durch die Gegend gehovert bin, dann sah es recht gut aus.
Aber schon ein YAW+Roll-Kurvenflug reichte, um das Bild schlechter werden zu lassen, wenn es etwas schneller war. Also wenn der Copter mehr Leistung gezogen hat.
OK, ein 30/35A-Burst ESC, und ein 25+ Lipo passen nicht soo wirklich zusammen, aber kommt später dran.
Zum Testen habe ich ein 12V auf 5V UBEC (3A) direkt mit einem Lipo verbunden, einfach um eine ausreichende Stromversorgung zu garantieren und äußere Einflüsse auszuschließen. Das ganze also via JST an GPIO (http://www.openmediacentre.com.au/fileadmin/_processed_/csm_raspberry_pi_with_y_shaped_usb_and_usb_gpio2_6a450b0783.jpg).
Meinst Du in deinem Setup liefert das UBEC nicht genug A wenn der Kopter viel Leistung zieht?
Ich werde mein Setup die Tage mit einer angetaubten Graupner testen. Ich gehe inzwischen jede Wette ein das die Turnigy i6 Billo-Funke ziemlichen Mist macht
Meinst Du in deinem Setup liefert das UBEC nicht genug A wenn der Kopter viel Leistung zieht?
Ich werde mein Setup die Tage mit einer angetaubten Graupner testen. Ich gehe inzwischen jede Wette ein das die Turnigy i6 Billo-Funke ziemlichen Mist macht
Hi Schluff81,
aha.. per GPIO.. na ja, dann solltest Du zumindest wissen, dass Du dann HINTER dem Spannungsüberwacher angeschlossen hast.
Ich habe meinen direkt hinter der USB-Buchse an der Rückseite angeschlossen und damit noch VOR dem Spannungsüberwachungs-Chip. Weiter habe ich mir eine einfache Steckverbindung gemacht.
Schau mal.. ich glaube so um die Seite 10-15, da habe ich mal ein Bild gepostet.
Ja aber das ist ja, was ich meine. Du speist den PI an sich mit 5V ein, nicht den Stick für sich alleine.
Aber genau DAS war es, was ich meinte.
Denn bei Deiner Varianten und wohl von allen Anderen und einschließlich mir bisher, wird der Stick über den PI per USB-Buchse mit Strom versorgt. DAS geht aber "eigentlich" nur bis zu einem gewissen Maße.
Bei Dir und alle die über die GPIO gehen wohl besser, weil bei mir noch das "Sicherungs-IC" dazwischen ist, das verhindert, dass zu viel Strom fließen kann.
Ob jetzt meine Variante, oder Deine besser ist, kann ich nicht sagen.
Ich habe heute Morgen mal die USB-Buchse ausgelötet an meinem irgendwie nicht so gut funktionierenden PI B, da hatte ich mit meinen Gedanken noch keinen Erfolg, den Stick parallel zum speisenden Strom vom PI Selbst anzuschließen.
Kann jetzt aber auch nicht sagen, woran es liegt. Ich hatte dann keine Zeit mehr dem nach zu gehen.
-----
Habe es eben noch mal in Ruhe getestet:
Es lag am Camera-Kabel, das war nicht ganz korrekt drin.
Es läuft alles, und das sogar besser als vorher.
Beim booten hatte ich vor immer mal wieder den bunten Würfel kurz drin, länger wenn WLAN angesteuert wurde.
Zwei Sticks.. da hat er gar nicht gebootet "Kernelpanik".
Mit dem Alpha AWUS036NHR 2000mW alleine, kaum sauberes booten möglich.
Jetzt, kann ich sogar ZWEI Stick gleichzeitig betreiben, und beide sogar mit USB-Verlängerung, was vorher schon mit einem schon nicht ging.
Ich für mich, ziehe den Schluss, den USB-Block auslöten, und extern mit Strom versorgen!
aha.. per GPIO.. na ja, dann solltest Du zumindest wissen, dass Du dann HINTER dem Spannungsüberwacher angeschlossen hast.
Ich habe meinen direkt hinter der USB-Buchse an der Rückseite angeschlossen und damit noch VOR dem Spannungsüberwachungs-Chip. Weiter habe ich mir eine einfache Steckverbindung gemacht.
Schau mal.. ich glaube so um die Seite 10-15, da habe ich mal ein Bild gepostet.
Ja aber das ist ja, was ich meine. Du speist den PI an sich mit 5V ein, nicht den Stick für sich alleine.
Aber genau DAS war es, was ich meinte.
Denn bei Deiner Varianten und wohl von allen Anderen und einschließlich mir bisher, wird der Stick über den PI per USB-Buchse mit Strom versorgt. DAS geht aber "eigentlich" nur bis zu einem gewissen Maße.
Bei Dir und alle die über die GPIO gehen wohl besser, weil bei mir noch das "Sicherungs-IC" dazwischen ist, das verhindert, dass zu viel Strom fließen kann.
Ob jetzt meine Variante, oder Deine besser ist, kann ich nicht sagen.
Ich habe heute Morgen mal die USB-Buchse ausgelötet an meinem irgendwie nicht so gut funktionierenden PI B, da hatte ich mit meinen Gedanken noch keinen Erfolg, den Stick parallel zum speisenden Strom vom PI Selbst anzuschließen.
Kann jetzt aber auch nicht sagen, woran es liegt. Ich hatte dann keine Zeit mehr dem nach zu gehen.
-----
Habe es eben noch mal in Ruhe getestet:
Es lag am Camera-Kabel, das war nicht ganz korrekt drin.
Es läuft alles, und das sogar besser als vorher.
Beim booten hatte ich vor immer mal wieder den bunten Würfel kurz drin, länger wenn WLAN angesteuert wurde.
Zwei Sticks.. da hat er gar nicht gebootet "Kernelpanik".
Mit dem Alpha AWUS036NHR 2000mW alleine, kaum sauberes booten möglich.
Jetzt, kann ich sogar ZWEI Stick gleichzeitig betreiben, und beide sogar mit USB-Verlängerung, was vorher schon mit einem schon nicht ging.
Ich für mich, ziehe den Schluss, den USB-Block auslöten, und extern mit Strom versorgen!
Zuletzt bearbeitet:
Schluff81, ich habe heute einen ersten Test gemacht, mit Funke und im Unterschied von 2,4GHz Ch13, Indoor zu 2,3GHz, CH-9.
Des weiteren an Änderungen, halt der RasPI B, mit umgebauter USB-Buchse, als "Prove-of-Conzept", also nicht die endgültige Lösung.
Ich mache gerade mal zwei Video´s etwas kleiner, dann könnt ihr den Unterschied selber sehen.
So wie sich das hier im kleinen Indoor-test zeigt mit 2,4GHz, hatte ich das auch draußen so ab 60m.
Kommen gleich als Nachtrag .
Schade, man kann kleine mp4, nicht direkt hier hoch laden, nur als URL, deshalb mal das ZIP.
Es sind zwei ca. 1MB große, rund 6-7sec. lange Video´s, die nur die Cam auf dem Copter unscharf zeigen. Im 2,4GHz Video, sieht man aber die vielen Artefakte, die im 2,3GHz video kpl. alle weg sind.
Anhang anzeigen Kurztest_2.4GHz-2.3GHz.zip
Ein gaaanz kurzer Test auf der Wiese hat das bestätigt. Da wo ich sonst nach rund 50-60m schon die ersten Artefakte bekam, da war jetzt noch ein sauberes Bild, bis ca. 80-90m (dann kam der Wald).
Dann habe ich über ein längeres Feld noch mal weiter geflogen und es zeigte sich auch hier... deutlich besseres Bild, und weniger Artefakte, bis .. schätze mal 100-120m... dann.. schwarzes Bild.
Ich holte den Kopter zurück.. und es ergab sich eins zum anderen. Der GPS-Pilz hatte sich gelöst und rotierte wohl etwas... und der Bildschirmschoner hatte zugeschlagen, so dass ich nicht mehr wußte, wie genau der Copter steht.
Dummerweise hatte bzw. konnte ich für diesen Test, den Monitor nur so aufstellen, dass der Copter hinter mir war (war halt noch viel zu nass rundherum) und ehe ich mich versah, hing der Copter in rund 15m Höhe im deutschen Eichenbaum fest, halb über dem matschigen Feld. Na klasse.
Mit sehr viel Glück, und dank der kräftigen T-Motoren, habe ich dann den Copter noch mal raus bekommen.. wenn auch nicht ganz unbeschädigt, aber es hält sich in Grenzen und ist leicht zu reparieren.
Dennoch kann ich sagen, die Richtung mit 2.3GHz scheint gut zu sein.
Testequipment: Copter mit Raspberry PI B, 2.3GHz Ch -9, 6DBi std. Stabantenne an einem TP-Link WN722N, als Funke eine Graupner MX-20, mit einem GR-16 Empfänger
Laptop, mit Tomm´s Lubuntu, 2x WN722N, std. Stabantenne 6DBi
Zuhause gemessene Latenz, lag leider noch bei rund 250-280ms
Im normalen Flug.. na ja geht so. Einen Racer würde ich damit nicht fliegen wollen.
Ach ja, zu den Einstellungen:
#adapt these to your needs
NIC="wlan0"
CHANNEL="-9"
WIDTH=1280
HEIGHT=720
FPS=30
BITRATE=4000000
KEYFRAMERATE=48
RETRANSMISSIONRATE=2
##################################
#change these only if you know what you are doing (and remember to change them on both sides)
BLOCK_SIZE=8
FECS=4
PACKET_LENGTH=1024
PORT=0
ToDo:
1. Pi-Image um den Treiber für einen RTL8188ru erweitern und dann einen Aplha AWUS36NHR mit 16DBi Stab testen.
Die beiden RX-Sticks auch mit 16DBi bestücken.
2. Skew Planar & cloverleave bauen und testen.
3. zweoi Helix bauen und an der Ground testen.
4. Latenzoptimierung
5. Copter wieder Flugfertig machen und gleichzeitig Optimierungen vornehmen, die ohnehin geplant waren.
6. auf Raspberrry Pi 2B Lieferung warten .... ;-) und neue Test mit Latenz.
7. Vielleicht noch eine doppel-BiQuad-Antenne (laut Befi) bauen und testen.
Vorteil seh ich in der doppel BiQuad, da sie recht weit streut, aber dennoch etwas in Richtung Helix hat.
Also nicht ganz wie eine "Helix-Keule", sondern mehr wie ein Megaphon, das aber wie die Bauweise der Antenne, nicht so nach oben und unten streut, aber nach rechts und links.
Des weiteren an Änderungen, halt der RasPI B, mit umgebauter USB-Buchse, als "Prove-of-Conzept", also nicht die endgültige Lösung.
Ich mache gerade mal zwei Video´s etwas kleiner, dann könnt ihr den Unterschied selber sehen.
So wie sich das hier im kleinen Indoor-test zeigt mit 2,4GHz, hatte ich das auch draußen so ab 60m.
Kommen gleich als Nachtrag .
Schade, man kann kleine mp4, nicht direkt hier hoch laden, nur als URL, deshalb mal das ZIP.
Es sind zwei ca. 1MB große, rund 6-7sec. lange Video´s, die nur die Cam auf dem Copter unscharf zeigen. Im 2,4GHz Video, sieht man aber die vielen Artefakte, die im 2,3GHz video kpl. alle weg sind.
Anhang anzeigen Kurztest_2.4GHz-2.3GHz.zip
Ein gaaanz kurzer Test auf der Wiese hat das bestätigt. Da wo ich sonst nach rund 50-60m schon die ersten Artefakte bekam, da war jetzt noch ein sauberes Bild, bis ca. 80-90m (dann kam der Wald).
Dann habe ich über ein längeres Feld noch mal weiter geflogen und es zeigte sich auch hier... deutlich besseres Bild, und weniger Artefakte, bis .. schätze mal 100-120m... dann.. schwarzes Bild.
Ich holte den Kopter zurück.. und es ergab sich eins zum anderen. Der GPS-Pilz hatte sich gelöst und rotierte wohl etwas... und der Bildschirmschoner hatte zugeschlagen, so dass ich nicht mehr wußte, wie genau der Copter steht.
Dummerweise hatte bzw. konnte ich für diesen Test, den Monitor nur so aufstellen, dass der Copter hinter mir war (war halt noch viel zu nass rundherum) und ehe ich mich versah, hing der Copter in rund 15m Höhe im deutschen Eichenbaum fest, halb über dem matschigen Feld. Na klasse.
Mit sehr viel Glück, und dank der kräftigen T-Motoren, habe ich dann den Copter noch mal raus bekommen.. wenn auch nicht ganz unbeschädigt, aber es hält sich in Grenzen und ist leicht zu reparieren.
Dennoch kann ich sagen, die Richtung mit 2.3GHz scheint gut zu sein.
Testequipment: Copter mit Raspberry PI B, 2.3GHz Ch -9, 6DBi std. Stabantenne an einem TP-Link WN722N, als Funke eine Graupner MX-20, mit einem GR-16 Empfänger
Laptop, mit Tomm´s Lubuntu, 2x WN722N, std. Stabantenne 6DBi
Zuhause gemessene Latenz, lag leider noch bei rund 250-280ms
Im normalen Flug.. na ja geht so. Einen Racer würde ich damit nicht fliegen wollen.
Ach ja, zu den Einstellungen:
#adapt these to your needs
NIC="wlan0"
CHANNEL="-9"
WIDTH=1280
HEIGHT=720
FPS=30
BITRATE=4000000
KEYFRAMERATE=48
RETRANSMISSIONRATE=2
##################################
#change these only if you know what you are doing (and remember to change them on both sides)
BLOCK_SIZE=8
FECS=4
PACKET_LENGTH=1024
PORT=0
ToDo:
1. Pi-Image um den Treiber für einen RTL8188ru erweitern und dann einen Aplha AWUS36NHR mit 16DBi Stab testen.
Die beiden RX-Sticks auch mit 16DBi bestücken.
2. Skew Planar & cloverleave bauen und testen.
3. zweoi Helix bauen und an der Ground testen.
4. Latenzoptimierung
5. Copter wieder Flugfertig machen und gleichzeitig Optimierungen vornehmen, die ohnehin geplant waren.
6. auf Raspberrry Pi 2B Lieferung warten .... ;-) und neue Test mit Latenz.
7. Vielleicht noch eine doppel-BiQuad-Antenne (laut Befi) bauen und testen.
Vorteil seh ich in der doppel BiQuad, da sie recht weit streut, aber dennoch etwas in Richtung Helix hat.
Also nicht ganz wie eine "Helix-Keule", sondern mehr wie ein Megaphon, das aber wie die Bauweise der Antenne, nicht so nach oben und unten streut, aber nach rechts und links.
Zuletzt bearbeitet:
@just_different: Erhöh mal die Frames auf 48 und die Latenz wird sich deutlich verringern
@schluff: eine DX5e sendet auch anders wie übliche Sender. Sie sucht sich beim Einschalten 3 freie Kanäle und hoppt auf den 3. Nachteil: Die 3 Kanäle bleiben fest eingestellt, auch wenn sie mal nicht mehr frei sind..
@schluff: eine DX5e sendet auch anders wie übliche Sender. Sie sucht sich beim Einschalten 3 freie Kanäle und hoppt auf den 3. Nachteil: Die 3 Kanäle bleiben fest eingestellt, auch wenn sie mal nicht mehr frei sind..
@Moritzz06: Das hatte ich am Anfang auch schon mal.. da aber noch Indoor und offline vom Copter, einfach so auf dem Tisch.
Hmm, lag auch bei rund 200-240ms.
Ich hatte auch extreme Werte versucht FPS 60 /Blockgr. 5500000 / Keyframe 60, (oder auch mal alle <-Werte halbiert) bleibt eigentlich fast immer gleich.. erhöht sich so um 50ms im schlechteren Fall.
Ich werde es auch noch mal mit einem PI b als TX, und einem PI B+ als RX versuchen. Damit hatte ich eigentlich die besten Werte (wie von Dir vorgeschlagen), von rund 170-190ms. Allerdings beim speichern, gehen sie dann auf rund 300ms, egal ob auf TX oder RX-Seite.
Hoffentlich kommt bald mal der PI2b.
Hmm, lag auch bei rund 200-240ms.
Ich hatte auch extreme Werte versucht FPS 60 /Blockgr. 5500000 / Keyframe 60, (oder auch mal alle <-Werte halbiert) bleibt eigentlich fast immer gleich.. erhöht sich so um 50ms im schlechteren Fall.
Ich werde es auch noch mal mit einem PI b als TX, und einem PI B+ als RX versuchen. Damit hatte ich eigentlich die besten Werte (wie von Dir vorgeschlagen), von rund 170-190ms. Allerdings beim speichern, gehen sie dann auf rund 300ms, egal ob auf TX oder RX-Seite.
Hoffentlich kommt bald mal der PI2b.
@modellbaupongo: Na ja, bisher wurde mein Alpha eben NICHT korrekt erkannt für die 2.3GHz und dies IST ein 8188ru (AWUS036NHR). Ich will mir also keinen kaufen, ich habe ihn bereits.
Daher dachte ich, ich muss den erst noch "einbauen", so wie das mit dem ath9K für die 2.3GHz ja auch nötig ist.
Liege ich da jetzt falsch?
Ich werde es gleich noch mal genauer testen, hatt eich seit Umbau mit der Stromversorgung noch nicht gemacht.
Daher dachte ich, ich muss den erst noch "einbauen", so wie das mit dem ath9K für die 2.3GHz ja auch nötig ist.
Liege ich da jetzt falsch?
Ich werde es gleich noch mal genauer testen, hatt eich seit Umbau mit der Stromversorgung noch nicht gemacht.
Es gibt hier den einen oder Anderen, der bereits eine Lösung für sich hat.
Jeder scheint unterschiedlich zu sein, und welche besser ist.. keine Ahnung.
Ich wollte es mit einem Arduino mache Mini pro 16MHz, doch das scheint schwieriger zu werden als gedacht.
Einen Tipp von mir, wie ich festellen musste, sind die billig Arduino´s aus China, definitiv nicht zu empfehlen.
Problem, FTDI, die die Treiberbausteine zum USB-Port herstellen/liefern, hatte was in seine Treiber eingebaut, so dass die Fake-ID´s nciht mehr angesprochen weden konnte/können.
Laut einem Forum, soll der Treiber 2.10.0.x wohl noch funktionieren, wenn man von Hand installiert (aktuell 2.12.x).
Aber wie ich gestern dann feststellen dufte, klappt das nicht immer und in jeder Konstellation. Manchmal läßt sich der Treiber nicht installieren, weil Windows es verweigert (Code 10).
Einen Vorteil, den ich in einem Arduino gesehen habe, ich hätte die Möglichkeit, zusätzlich zu dein Infos, die die NAZA bietet, z.B. auch einen Sonar-Sensor anzubringen, den die NAZA eigentlich gar nicht bedienen kann, aber eben über den Arduino.
Soweit ich das gelesen habe, mist der Sonar-Sensor zwar erst oder bzw. maximal bis ca. 4m Höhe, aber dafür schneller und genauer als es über GPS/Baro möglich ist.
Jeder scheint unterschiedlich zu sein, und welche besser ist.. keine Ahnung.
Ich wollte es mit einem Arduino mache Mini pro 16MHz, doch das scheint schwieriger zu werden als gedacht.
Einen Tipp von mir, wie ich festellen musste, sind die billig Arduino´s aus China, definitiv nicht zu empfehlen.
Problem, FTDI, die die Treiberbausteine zum USB-Port herstellen/liefern, hatte was in seine Treiber eingebaut, so dass die Fake-ID´s nciht mehr angesprochen weden konnte/können.
Laut einem Forum, soll der Treiber 2.10.0.x wohl noch funktionieren, wenn man von Hand installiert (aktuell 2.12.x).
Aber wie ich gestern dann feststellen dufte, klappt das nicht immer und in jeder Konstellation. Manchmal läßt sich der Treiber nicht installieren, weil Windows es verweigert (Code 10).
Einen Vorteil, den ich in einem Arduino gesehen habe, ich hätte die Möglichkeit, zusätzlich zu dein Infos, die die NAZA bietet, z.B. auch einen Sonar-Sensor anzubringen, den die NAZA eigentlich gar nicht bedienen kann, aber eben über den Arduino.
Soweit ich das gelesen habe, mist der Sonar-Sensor zwar erst oder bzw. maximal bis ca. 4m Höhe, aber dafür schneller und genauer als es über GPS/Baro möglich ist.
Hat schon jemand Erfahrungen mit dem Parameter "PACKET_LENGTH" gesammelt?
Hatte diesen Parameter schon im alten Code deaktiviert da er jede Menge Artefakte produzierte.
Jetzt wo ich den neuen Code mit FEC aufgespielt hatte mit den neuen Scripten war dieser wieder aktiv und ich hatte bis zum Deaktivieren von diesem wieder jede Menge Artefakte.
Hat jemand die gleichen Erfahrungen gemacht?
Hatte diesen Parameter schon im alten Code deaktiviert da er jede Menge Artefakte produzierte.
Jetzt wo ich den neuen Code mit FEC aufgespielt hatte mit den neuen Scripten war dieser wieder aktiv und ich hatte bis zum Deaktivieren von diesem wieder jede Menge Artefakte.
Hat jemand die gleichen Erfahrungen gemacht?
- Status
