EZ-Wifibroadcast, HD FPV in günstig und einfach
- Themenstarter rodizio
- Beginndatum
- Status
Hallo Rodizio,
Exzellente Arbeit! Komme grad nach Hause und habs direkt mal ausprobiert! Schaut direkt out of the Box schon mal prima aus! =)
Das einzige was mich irritiert... Er zeigt mir kurz nach dem Einschalten "under voltage or over temperature at TX" obwohl der verwendete Akku knallvoll ist. Vielleicht liegts an meinem betagten Raspi A+? (wie dem auch sei... läuft super!)
Wäre es ein Großes neben FrySky iBUS auch SBUS zu unterstützen? Viele FCs können mit iBUS noch nicht umgehen (z.B. APM, Pixhawk oder wie in meinem Fall Pixracer). Die beiden Protokolle sollten doch recht ähnlich sein und SBUS ist deutlich weiter verbreitet und nicht Hersteller proprietär.
Auf jeden Fall schon mal ein dickes Danke und KUDOS! *verneig*
Exzellente Arbeit! Komme grad nach Hause und habs direkt mal ausprobiert! Schaut direkt out of the Box schon mal prima aus! =)
Das einzige was mich irritiert... Er zeigt mir kurz nach dem Einschalten "under voltage or over temperature at TX" obwohl der verwendete Akku knallvoll ist. Vielleicht liegts an meinem betagten Raspi A+? (wie dem auch sei... läuft super!)
Wäre es ein Großes neben FrySky iBUS auch SBUS zu unterstützen? Viele FCs können mit iBUS noch nicht umgehen (z.B. APM, Pixhawk oder wie in meinem Fall Pixracer). Die beiden Protokolle sollten doch recht ähnlich sein und SBUS ist deutlich weiter verbreitet und nicht Hersteller proprietär.
Auf jeden Fall schon mal ein dickes Danke und KUDOS! *verneig*
Zuletzt bearbeitet:
Schön dass es direkt läuft 
Achja, das sollte ich vielleicht noch dazusagen: Der TX misst jetzt bevor die Videoübertragung losgeht die verfügbare max. Bandbreite und setzt daraufhin die entsprechende Videobitrate (65% der max. Bandbreite mit default settings). Dazu gibt er zwei Sekunden 'Vollgas', der 052NH verbrät dabei bis zu 1.8A ...
Wenn Ihr jetzt mit 1.6 eine Undervoltage-Warnung bekommt die mit 1.5 nicht da war, dann ist das kein Bug, sondern eine Stromversorgung, die bei 'Normalbetrieb' (052NH ca. 1.4A, schwankend) gerade noch so klar kommt, bei 'Vollgas' aber nicht, d.h. die Stromversorgung war sowieso schon nicht wirklich gut, sondern gerade an der Grenze zum Undervoltage ...
Wegen SBUS: Das Protokoll ist inhärent unsicher weil es keine Checksummen und auch keine sauber erkennbaren start- oder endmarker hat und funktioniert nur solange das Timing präzise eingehalten wird. Das kann man mit einem non-realtime OS wie Linux (und dazu noch die darunterliegende Pi Firmware) nicht garantieren. Wenn's schief geht, führt das nicht zu 'keine Steuerung mehr' sondern 'Steuerung spielt völlig verrückt' weil komplett zufällige Werte interpretiert werden. Dazu kommt noch das nervige Inverter-Gefrickel und die 'krummen' 100.000baud und parity settings. Nein danke
Laut der Ardupilot Seite soll aber Multiplex SRXL gehen. Oder halt über Mavlink, das spart auch einen seriellen Port (theoretisch sollte es über den gleichen seriellen Port gehen).
Achja, das sollte ich vielleicht noch dazusagen: Der TX misst jetzt bevor die Videoübertragung losgeht die verfügbare max. Bandbreite und setzt daraufhin die entsprechende Videobitrate (65% der max. Bandbreite mit default settings). Dazu gibt er zwei Sekunden 'Vollgas', der 052NH verbrät dabei bis zu 1.8A ...
Wenn Ihr jetzt mit 1.6 eine Undervoltage-Warnung bekommt die mit 1.5 nicht da war, dann ist das kein Bug, sondern eine Stromversorgung, die bei 'Normalbetrieb' (052NH ca. 1.4A, schwankend) gerade noch so klar kommt, bei 'Vollgas' aber nicht, d.h. die Stromversorgung war sowieso schon nicht wirklich gut, sondern gerade an der Grenze zum Undervoltage ...
Wegen SBUS: Das Protokoll ist inhärent unsicher weil es keine Checksummen und auch keine sauber erkennbaren start- oder endmarker hat und funktioniert nur solange das Timing präzise eingehalten wird. Das kann man mit einem non-realtime OS wie Linux (und dazu noch die darunterliegende Pi Firmware) nicht garantieren. Wenn's schief geht, führt das nicht zu 'keine Steuerung mehr' sondern 'Steuerung spielt völlig verrückt' weil komplett zufällige Werte interpretiert werden. Dazu kommt noch das nervige Inverter-Gefrickel und die 'krummen' 100.000baud und parity settings. Nein danke
Laut der Ardupilot Seite soll aber Multiplex SRXL gehen. Oder halt über Mavlink, das spart auch einen seriellen Port (theoretisch sollte es über den gleichen seriellen Port gehen).
Zuletzt bearbeitet:
Hallo Rodizio,
vielen Dank für die Erklärung. Das war mir so im Detail gar nicht bewusst. In der Tat ist iBUS dann natürlich die bessere Alternative. Ich werde dann einfach einen iBUS nach PPM+SBUS Adapter einsetzen (gibt es günstig bei Banggood). Mavlink kann ich nicht benutzen, da ich mehr als 8 Kanäle am Kopter benötige. Aber mit dem Adapter wird es dann gehen. (Der Adapter muss eh sein, da ich im Kopter sowieso 8 Kanäle als einzelne PPM Signale ausschleifen muss)
Das mit dem Vorab-Test in Bezug auf die Spannungsversorgung ist natürlich super. Wundert mich nur, dass er die Message bei mir wirft, da ich ein dickes 5A BEC nutze mit Puffer-Elkos und dicken Leitungen. Darum vermute ich, dass ggf. der Raspi A+ (den nutze ich nur auf meinem Test-Setup) etwas ins Schwitzen kommt, also der zweite Part der Message "overtemperature" zutrifft.
Aufgefallen ist mir auch, dass die Message wenn sie einmal da ist dauerhaft angezeigt wird... könnte man das so einstellen, dass die Message nach ggf. 10sec ausgebeldet wird und wieder kommt, wenn die Spannung erneut einsackt? Wäre auch super, wenn man die beiden Message Inhalte "Undervoltage" und "Overtemperature" voneinander entkoppeln könnte, so dass man zielsicher weiß was los ist. Das mit der automatisch angepassten Bitrate habe ich auch noch nicht ganz verstanden.... in der Config sind ja 65% fix gesetzt, müsste das nicht auf AUTO stehen, damit der 2sec Testlauf am Anfang sinnvoll ist? Sorry für die dumme Frage, aber ich habe es wie gesagt noch nicht ganz verstanden.
Was ich gestern noch nicht testen konnte waren die ganzen Konfigurationen bzgl. des OSDs. Hast du auch z.B. die "Radarkarte" von Frank (dino) übernehmen können? Die ist einfach nur super und extrem hilfreich beim Fliegen.
Liebe Grüße und mach weiter so!
Thomas
vielen Dank für die Erklärung. Das war mir so im Detail gar nicht bewusst. In der Tat ist iBUS dann natürlich die bessere Alternative. Ich werde dann einfach einen iBUS nach PPM+SBUS Adapter einsetzen (gibt es günstig bei Banggood). Mavlink kann ich nicht benutzen, da ich mehr als 8 Kanäle am Kopter benötige. Aber mit dem Adapter wird es dann gehen. (Der Adapter muss eh sein, da ich im Kopter sowieso 8 Kanäle als einzelne PPM Signale ausschleifen muss)
Das mit dem Vorab-Test in Bezug auf die Spannungsversorgung ist natürlich super. Wundert mich nur, dass er die Message bei mir wirft, da ich ein dickes 5A BEC nutze mit Puffer-Elkos und dicken Leitungen. Darum vermute ich, dass ggf. der Raspi A+ (den nutze ich nur auf meinem Test-Setup) etwas ins Schwitzen kommt, also der zweite Part der Message "overtemperature" zutrifft.
Aufgefallen ist mir auch, dass die Message wenn sie einmal da ist dauerhaft angezeigt wird... könnte man das so einstellen, dass die Message nach ggf. 10sec ausgebeldet wird und wieder kommt, wenn die Spannung erneut einsackt? Wäre auch super, wenn man die beiden Message Inhalte "Undervoltage" und "Overtemperature" voneinander entkoppeln könnte, so dass man zielsicher weiß was los ist. Das mit der automatisch angepassten Bitrate habe ich auch noch nicht ganz verstanden.... in der Config sind ja 65% fix gesetzt, müsste das nicht auf AUTO stehen, damit der 2sec Testlauf am Anfang sinnvoll ist? Sorry für die dumme Frage, aber ich habe es wie gesagt noch nicht ganz verstanden.
Was ich gestern noch nicht testen konnte waren die ganzen Konfigurationen bzgl. des OSDs. Hast du auch z.B. die "Radarkarte" von Frank (dino) übernehmen können? Die ist einfach nur super und extrem hilfreich beim Fliegen.
Liebe Grüße und mach weiter so!
Thomas
Zuletzt bearbeitet:
Hmm, mir fällt gerade ein, ich habe die Logik für mehr als 8 Kanäle noch garnicht eingebaut für die anderen Protokolle, sorry das wird nicht gehen. Ich schau' mal ob ich das bis zur Final noch hinbekomme.
Wegen der Warnung: Ist das so ein alter Pi1 mit gelbem Chinch Anschluss anstatt 3.5mm Klinke? Die alten Dinger hatten lt. Raspberry Forum alle möglichen Stromversorgungs- und USB-Probleme, kann sein dass das daran liegt. Ich habe nur den neuen A+ und keine alten, kann daher nicht testen damit.
Ob es Overtemp oder Undervolt ist lässt sich nicht so leicht herauskriegen, ist irgendwie alles etwas schlecht dokumentiert. Wenn der Pi aber gerade erst eingeschaltet wurde, war es garantiert nicht die Temperatur, innerhalb von 30s wird der nicht so heiss.
Die Meldung dynamisch machen wäre recht viel Aufwand, vielleicht irgendwann mal.
So irgendwas weiter testen kannst Du dir sparen, wenn die Meldung kommt, wird die Bitrate auf 3mbit festgesetzt (damit die Karte weniger Strom zieht und es hoffentlich noch reicht um zu senden).
Wegen der Bandbreite und Einstellungen werde ich noch das Wiki anpassen.
Die Logik dahinter ist: Man stellt Wifi Bitrate und FEC settings ein, dann misst der TX die maximale Bandbreite (mit genau den Einstellungen) und nimmt davon dann 65% als die Videbitrate (um noch Luft für Bitrate-Schwankungen zu haben).
Bei 1.5 war das mit festen Profilen gelöst, das schränkt aber doch recht stark ein, mit der 1.6 könnt Ihr jetzt je nach Anwendung und Umgebung etc. frei einstellen.
OSD von Frank kommt leider erst in 1.7 (aber ich werde zusehen, dass ich kürzere Release-Cycles mache ...) auf RCGroups haben auch noch zwei weitere Leute Code beigesteuert und dann gibt's auch noch das neue OSD von svpcom (der hat das Playuav OSD auf den Pi portiert, sieht vielversprechend aus), weiss noch garnicht wie ich das alles unter einen Hut kriegen soll ...
Wegen der Warnung: Ist das so ein alter Pi1 mit gelbem Chinch Anschluss anstatt 3.5mm Klinke? Die alten Dinger hatten lt. Raspberry Forum alle möglichen Stromversorgungs- und USB-Probleme, kann sein dass das daran liegt. Ich habe nur den neuen A+ und keine alten, kann daher nicht testen damit.
Ob es Overtemp oder Undervolt ist lässt sich nicht so leicht herauskriegen, ist irgendwie alles etwas schlecht dokumentiert. Wenn der Pi aber gerade erst eingeschaltet wurde, war es garantiert nicht die Temperatur, innerhalb von 30s wird der nicht so heiss.
Die Meldung dynamisch machen wäre recht viel Aufwand, vielleicht irgendwann mal.
So irgendwas weiter testen kannst Du dir sparen, wenn die Meldung kommt, wird die Bitrate auf 3mbit festgesetzt (damit die Karte weniger Strom zieht und es hoffentlich noch reicht um zu senden).
Wegen der Bandbreite und Einstellungen werde ich noch das Wiki anpassen.
Die Logik dahinter ist: Man stellt Wifi Bitrate und FEC settings ein, dann misst der TX die maximale Bandbreite (mit genau den Einstellungen) und nimmt davon dann 65% als die Videbitrate (um noch Luft für Bitrate-Schwankungen zu haben).
Bei 1.5 war das mit festen Profilen gelöst, das schränkt aber doch recht stark ein, mit der 1.6 könnt Ihr jetzt je nach Anwendung und Umgebung etc. frei einstellen.
OSD von Frank kommt leider erst in 1.7 (aber ich werde zusehen, dass ich kürzere Release-Cycles mache ...) auf RCGroups haben auch noch zwei weitere Leute Code beigesteuert und dann gibt's auch noch das neue OSD von svpcom (der hat das Playuav OSD auf den Pi portiert, sieht vielversprechend aus), weiss noch garnicht wie ich das alles unter einen Hut kriegen soll ...
Habe noch etwas mehr Telemetrie debug logging zum OSD hinzugefügt, wenn irgendwas mit Telemetrie nicht funktioniert, kopiert die mavlink.c bitte nach /root/wifibroadcast_osd/ (die vorhandene Datei überschreiben).
Dann nach dem Testen einen USB stick anstecken um telemetrylog.txt und telemetrylog.raw zu sichern.
Anhang anzeigen mavlink.zip
Dann nach dem Testen einen USB stick anstecken um telemetrylog.txt und telemetrylog.raw zu sichern.
Anhang anzeigen mavlink.zip
Das (>8 Kanäle abseits von MavLink) wäre natürlich ein Träumchen! Hoffentlich klappts! =D
Ich nutze wie gesagt auch einen A+ ... das ist quasi der Vorgänger zum Zero und CPU seitig mit 700Mhz etwas schwächer auf der Brust. Ist dieser hier: https://www.raspberrypi.org/products/raspberry-pi-1-model/. Als Sender nuckelt ein 052NH am Strom.
Okay, dann teste ich nochmal... Vielleicht hatte ich auch nur irgendeinen F+++! ;-)
Das mit den getrennten Messages war nur so eine dumme Idee.
Hurra! Das wäre toll... Bin auch auf die anderen OSDs gespannt. Das von Frank ist zum Fliegen auf jeden Fall schon mal sehr geil, weil man immer weiß wo man relativ zu sich mit dem Flieger ist und wo's nach Hause geht. Orientierung damit zu verlieren ist quasi unmöglich.
Ich nutze wie gesagt auch einen A+ ... das ist quasi der Vorgänger zum Zero und CPU seitig mit 700Mhz etwas schwächer auf der Brust. Ist dieser hier: https://www.raspberrypi.org/products/raspberry-pi-1-model/. Als Sender nuckelt ein 052NH am Strom.
Okay, dann teste ich nochmal... Vielleicht hatte ich auch nur irgendeinen F+++! ;-)
Das mit den getrennten Messages war nur so eine dumme Idee.
Hurra! Das wäre toll... Bin auch auf die anderen OSDs gespannt. Das von Frank ist zum Fliegen auf jeden Fall schon mal sehr geil, weil man immer weiß wo man relativ zu sich mit dem Flieger ist und wo's nach Hause geht. Orientierung damit zu verlieren ist quasi unmöglich.
Der neue A+ sollte problemlos laufen, mit dem teste ich hier auch. Würde zum testen erstmal die Sendeleistung runterstellen damit Du erstmal weiterkommst.
Habe gerade v1.6RC2 fertiggestellt:
https://en.file-upload.net/download-12774875/EZ-Wifibroadcast-1.6RC2.zip.html
Changelog:
- telemetry downlink fixes
- replaced cmavnode with mavlink-routerd (supports UDP and TCP)
- more debug logging
- Version on boot-up and in readme.txt updated to reflect rc status
Habe gerade v1.6RC2 fertiggestellt:
https://en.file-upload.net/download-12774875/EZ-Wifibroadcast-1.6RC2.zip.html
Changelog:
- telemetry downlink fixes
- replaced cmavnode with mavlink-routerd (supports UDP and TCP)
- more debug logging
- Version on boot-up and in readme.txt updated to reflect rc status
Zuletzt bearbeitet:
War mir nicht sicher, ob cmavnode vielleicht für die Probleme mit dem Uplink (mit) verantwortlich ist. Auf Rcgroups ist jemand, bei dem geht Parameter-Abfragen und Dowlink-Telemetrie einwandfrei, nur Missionen und Kommandos scheinen irgendwie nicht ge-ackt zu werden, ich sehe aber command_ack pakete hereinkommen, von daher meine Theorie, dass cmavnode da vielleicht was nicht richtig weiterleitet.
Dann ist mir noch aufgefallen, dass Missionplanner mit cmavnode immer ca. 150ms als kleinsten Abstand zwischen den Pakete in den Stats anzeigt, mit mavlink-routerd sind's nur ca. 110ms, scheint die Pakete weniger zu verzögern.
Achja, RC2 loggt ziemlich viel, wenn irgendwas nicht geht, steckt bitte hinterher einen usb stick an und schickt mir die ganzen logs ...
Dann ist mir noch aufgefallen, dass Missionplanner mit cmavnode immer ca. 150ms als kleinsten Abstand zwischen den Pakete in den Stats anzeigt, mit mavlink-routerd sind's nur ca. 110ms, scheint die Pakete weniger zu verzögern.
Achja, RC2 loggt ziemlich viel, wenn irgendwas nicht geht, steckt bitte hinterher einen usb stick an und schickt mir die ganzen logs ...
Zuletzt bearbeitet:
Hey,
da ist schon etwas mehr Code vorhanden als ich mir vorgestellt habe, war etwas schwer lesbar deswegen hab ich erstmal nur die Einrückungen nachgebessert und Switches verkürzt.
Anhang anzeigen rx_rc_telemetry_buf.c.zip
Die Anzahl der Descriptors die angesehen werden soll (1-29), könnte man eigentlich auch auf num_interfaces setzen denk ich.
Ganz generell zum Verständnis: In der Endlosschleife wird alle 100ms Daten von allen lesbaren FDs gelesen. Alle Pakete werden dann auf die Serielle geschrieben (außer Pakete deren Sequenznummer im Header in der Runde schon gesehen wurden). Du schreibst jetzt in einen Buffer, sortierst den nach Telemetry Sequenznummer und schreibst dann auf die Serielle. Stimmt das so?
Nutzt du eigentlich Github oder Ähnliches?
LG
da ist schon etwas mehr Code vorhanden als ich mir vorgestellt habe, war etwas schwer lesbar deswegen hab ich erstmal nur die Einrückungen nachgebessert und Switches verkürzt.
Anhang anzeigen rx_rc_telemetry_buf.c.zip
Code:
int n = select(30, &readset, NULL, NULL, &to); // TODO: check how the 30 works exactlyGanz generell zum Verständnis: In der Endlosschleife wird alle 100ms Daten von allen lesbaren FDs gelesen. Alle Pakete werden dann auf die Serielle geschrieben (außer Pakete deren Sequenznummer im Header in der Runde schon gesehen wurden). Du schreibst jetzt in einen Buffer, sortierst den nach Telemetry Sequenznummer und schreibst dann auf die Serielle. Stimmt das so?
Nutzt du eigentlich Github oder Ähnliches?
LG
r0ck3t: Ja, der code ist dreckig und hässlich Die Logik ist genau wie Du es beschreibst. Wobei die Schleife nicht fest mit 100ms (oder 10Hz) läuft. Die 100ms sind nur der select timeout, die Schleife läuft praktisch mit der Geschwindigkeit, mit der die Daten reinkommen, select returned entweder wenn Daten angekommen sind oder nach 100ms.
Scheinbar kommen aber auch mit rc2 noch Pakete doppelt heraus. Die sequenz ist dann z.b. 100 - 101 - 100 - 101. Ich muss das noch so erweitern, dass er sich nicht nur die letzte, sondern die letzten paar seqnums merkt und vor dem ausgeben nochmal vergleicht, damit das nicht vorkommen kann. Und ein bisken aufräumen
Das mit den Deskriptoren ist irgendwie anders glaube, nicht die Anzahl an Deskriptoren sondern die höchste Nummer (aber ich weiss nicht wie man die ermittelt ...). Intern wird das irgendwie mit einer Bitmaske gemacht glaube. Ist aber erstmal nicht so wichtig, der Teil ist von Befinitiv, der wird das schon nicht ganz falsch gemacht haben. Dachte halt, dass lässt sich noch leicht optimieren ...
Careyer: Sehr schön Geht der Telemetrie Uplink?
Die Logik ist genau wie Du es beschreibst. Wobei die Schleife nicht fest mit 100ms (oder 10Hz) läuft. Die 100ms sind nur der select timeout, die Schleife läuft praktisch mit der Geschwindigkeit, mit der die Daten reinkommen, select returned entweder wenn Daten angekommen sind oder nach 100ms.Scheinbar kommen aber auch mit rc2 noch Pakete doppelt heraus. Die sequenz ist dann z.b. 100 - 101 - 100 - 101. Ich muss das noch so erweitern, dass er sich nicht nur die letzte, sondern die letzten paar seqnums merkt und vor dem ausgeben nochmal vergleicht, damit das nicht vorkommen kann. Und ein bisken aufräumen
Das mit den Deskriptoren ist irgendwie anders glaube, nicht die Anzahl an Deskriptoren sondern die höchste Nummer (aber ich weiss nicht wie man die ermittelt ...). Intern wird das irgendwie mit einer Bitmaske gemacht glaube. Ist aber erstmal nicht so wichtig, der Teil ist von Befinitiv, der wird das schon nicht ganz falsch gemacht haben. Dachte halt, dass lässt sich noch leicht optimieren ...
Careyer: Sehr schön
Geht der Telemetrie Uplink?
Zuletzt bearbeitet:
Nach etwas Abstinenz bin ich auch wieder im Boot.
Ich habe heute 1.6 RC2 mit einem PI3 als RX (AWUS052NH) und einem PI Zero als TX (AWUS051NH) im 5gHz Bereich vorerst im Haus getestet.
GEHT!
Alles scheint etwas flüssiger zu sein, durch 4 Wände hatte ich immer noch -51dB, mit der ALFA Richtantenne -41dB.
Rodizio, Hut ab!
Kann also im Wiki mit PI Zero als funktionierend eingetragen werden.
Ich habe heute 1.6 RC2 mit einem PI3 als RX (AWUS052NH) und einem PI Zero als TX (AWUS051NH) im 5gHz Bereich vorerst im Haus getestet.
GEHT!
Alles scheint etwas flüssiger zu sein, durch 4 Wände hatte ich immer noch -51dB, mit der ALFA Richtantenne -41dB.
Rodizio, Hut ab!
Kann also im Wiki mit PI Zero als funktionierend eingetragen werden.
Bitteschön.
Jetzt muss ich nur noch mit 6 Silikonlitzen "nach oben", zuvor war der PI 3 oberhalb und ich musste, aufgrund des 3 Achsen Gimbals, ein recht langes Folienkabel nutzen damit die Drehungen nicht blockiert werden.
Das flatterte aber anscheinend im Propwind und erzeugte teilweise Yellos.
Das müsste nun vorbei sein.
Jetzt muss ich nur noch mit 6 Silikonlitzen "nach oben", zuvor war der PI 3 oberhalb und ich musste, aufgrund des 3 Achsen Gimbals, ein recht langes Folienkabel nutzen damit die Drehungen nicht blockiert werden.
Das flatterte aber anscheinend im Propwind und erzeugte teilweise Yellos.
Das müsste nun vorbei sein.
- Status
