FRsky Taranis und Variometer FVAS-02H
- Themenstarter Tempo
- Beginndatum
- Status
Beispiel für Datenglättung mit FIR-Filter- Teil 2
So könnten geglättete Höhendaten aussehen, um sie anschließend für eine Variometerausgabe zu differenzieren:
Es bietet sich z.B. die hellblaue Glättung an.
Schön sieht man im Vergleich mit den anderen FIR-Filterauslegungen, welchen Einfluß die Filter-Ordnung auf die zeitliche Verschiebung hat oder welchen Einfluß der Fenstertyp für die Koeffizientenauslegung auf eine Verschiebung der Höhenwerte hat.
Fortsetzung Teil 3 mit 1dimensionalem-Kalman-Filter folgt ...
So könnten geglättete Höhendaten aussehen, um sie anschließend für eine Variometerausgabe zu differenzieren:
Es bietet sich z.B. die hellblaue Glättung an.
Schön sieht man im Vergleich mit den anderen FIR-Filterauslegungen, welchen Einfluß die Filter-Ordnung auf die zeitliche Verschiebung hat oder welchen Einfluß der Fenstertyp für die Koeffizientenauslegung auf eine Verschiebung der Höhenwerte hat.
Fortsetzung Teil 3 mit 1dimensionalem-Kalman-Filter folgt ...
Hallo,
warum so umständlich? Mit der einfachen Formel wie ein paar Beiträge zuvor dargestellt, giebt es dieses Ergebnis:
Wie man sieht, vollkommen ausreichend. Man könnte für diesen einfachen Fall sogar etwas reduzieren, aber eigentlich war die Formel ja für das Höhendifferenzsignal gedacht.
Ich weiss nicht, wie weit ihr in der Filtertheorie fit seid. Aber wie man anschaulich im vorigen Beispiel sieht, kann man auch übertreiben und erhält mit massivem Rechenaufwand schlechtere Ergebnisse. Wir benötigen kein Phasenverhalten. Und die verschiedenen Filtertypen beschreiben nur das einschwingverhalten und das Dämpfungsverhalten im Übergangsbereich. Für unsere Anwendung können wir kein Überschwingen brauchen und ein Zeitverzögerung von 20 oder 30 Samples ( = 3-5 sec) ist nicht akzeptabel.
Zumal fraglich ist, ob die Microprozessoren diese massive Gleitkommaberechnung überhaupt schaffen können. Wir müssen 10 komplette Durchgänge pro sec berechnen. Jede Schleife und jede Ordnung benötigt den FIR und anderen digitalen Filtern pro Koeffizierenten mehrere sinus und cosinus Berechnungen, neben den anderen Gleikomma Multiplikationen und Additionen. Da ist man schnell bei Mehreren tausend bis 10.000 Berechnungen pro sec???
Aber wie gesagt unnötig und nicht zielführend. Ich werde mich an FrSky wenden und nachfragen, ob sie nicht das Vario nachbessern wollen. Die technischen Voraussetzungen sind vorhanden. Ist nur ein Firmwareupdate.
warum so umständlich? Mit der einfachen Formel wie ein paar Beiträge zuvor dargestellt, giebt es dieses Ergebnis:
Wie man sieht, vollkommen ausreichend. Man könnte für diesen einfachen Fall sogar etwas reduzieren, aber eigentlich war die Formel ja für das Höhendifferenzsignal gedacht.
Ich weiss nicht, wie weit ihr in der Filtertheorie fit seid. Aber wie man anschaulich im vorigen Beispiel sieht, kann man auch übertreiben und erhält mit massivem Rechenaufwand schlechtere Ergebnisse. Wir benötigen kein Phasenverhalten. Und die verschiedenen Filtertypen beschreiben nur das einschwingverhalten und das Dämpfungsverhalten im Übergangsbereich. Für unsere Anwendung können wir kein Überschwingen brauchen und ein Zeitverzögerung von 20 oder 30 Samples ( = 3-5 sec) ist nicht akzeptabel.
Zumal fraglich ist, ob die Microprozessoren diese massive Gleitkommaberechnung überhaupt schaffen können. Wir müssen 10 komplette Durchgänge pro sec berechnen. Jede Schleife und jede Ordnung benötigt den FIR und anderen digitalen Filtern pro Koeffizierenten mehrere sinus und cosinus Berechnungen, neben den anderen Gleikomma Multiplikationen und Additionen. Da ist man schnell bei Mehreren tausend bis 10.000 Berechnungen pro sec???
Aber wie gesagt unnötig und nicht zielführend. Ich werde mich an FrSky wenden und nachfragen, ob sie nicht das Vario nachbessern wollen. Die technischen Voraussetzungen sind vorhanden. Ist nur ein Firmwareupdate.
Eine andere Überlegung ist das Vario von VSpeak. Ist ist 100% kompatibel mit der Telemetrie bei den D Empfängern. Einfach anschliessen und läuft. Haben zusätzlich einen Beschleunigungssensor und Einzelzellenüberwachung für 4 Lipos.
Kostenpunkt 59 Euro.
Wiess bloss nicht, wie gut das Ding ist. Soll auf 0,2mtr/s Höhenänderung auflösen.
Kostenpunkt 59 Euro.
Wiess bloss nicht, wie gut das Ding ist. Soll auf 0,2mtr/s Höhenänderung auflösen.
Moin
Mehr zum VSpeak Vario hier: http://www.vspeak-modell.de/de/vspeak-vario
Log-Funktion
Lipo Überwachung bis 4s
Beschleunigungssensor
Höhe relativ und
Vario
Laut Hersteller und Entwickler an Taranis erfolgreich getestet.
Ich habe eines hier und auch die Taranis, bin aber noch nicht so weit gekommen. Ausserdem fehlt mir zur Beurteilung der Vergleich zu anderen Varios.
Ich fand die Kombi mit der Lipo-Überwachung ganz charmant. Das Kabel zum Balancerstecker kostet extra. Speicherkarte ist nicht enthalten.
Gruss
Michael
Mehr zum VSpeak Vario hier: http://www.vspeak-modell.de/de/vspeak-vario
Log-Funktion
Lipo Überwachung bis 4s
Beschleunigungssensor
Höhe relativ und
Vario
Laut Hersteller und Entwickler an Taranis erfolgreich getestet.
Ich habe eines hier und auch die Taranis, bin aber noch nicht so weit gekommen. Ausserdem fehlt mir zur Beurteilung der Vergleich zu anderen Varios.
Ich fand die Kombi mit der Lipo-Überwachung ganz charmant. Das Kabel zum Balancerstecker kostet extra. Speicherkarte ist nicht enthalten.
Gruss
Michael
Dann sollte es wohl passen. Wenn die Steig/sinkrate angezeigt wird ist alles ok.
Eine dicke Bitte: Könntest du damit einen Log machen? einfach alles einschalten und 2 min liegen lassen ( damit sich das Vario stabilisiert. Während des LOGs darauf achten das Türen und Fenster geschlossen sind und keiner im Zimmer wild hin- und herläuft. Das Vario ruhig liegen lassen und 20 oder 30 sec aufnehmen. Dann auf den Boden legen, erneut Log starten und langsam vom Boden zur Decke anheben ( steigen simulieren), die gut 2mtr vieleicht in 10 oder 20 sec. Dann die logs von der Karte hier ins Forum stellen. Einfach wie es von der Karte kommt. Auswerten tue ich es schon selbst.
Damit würdest du sicher vielen einen Gefallen tun und vor Fehlkäufen bewahren.
Falls du mit den Einstellungen oder den Log nicht klarkommst, einfach melden - können auch Telefonseelsorge machen, das geht am schnellsten.
Eine dicke Bitte: Könntest du damit einen Log machen? einfach alles einschalten und 2 min liegen lassen ( damit sich das Vario stabilisiert. Während des LOGs darauf achten das Türen und Fenster geschlossen sind und keiner im Zimmer wild hin- und herläuft. Das Vario ruhig liegen lassen und 20 oder 30 sec aufnehmen. Dann auf den Boden legen, erneut Log starten und langsam vom Boden zur Decke anheben ( steigen simulieren), die gut 2mtr vieleicht in 10 oder 20 sec. Dann die logs von der Karte hier ins Forum stellen. Einfach wie es von der Karte kommt. Auswerten tue ich es schon selbst.
Damit würdest du sicher vielen einen Gefallen tun und vor Fehlkäufen bewahren.
Falls du mit den Einstellungen oder den Log nicht klarkommst, einfach melden - können auch Telefonseelsorge machen, das geht am schnellsten.
Was macht Norbert und was macht Tempo ?
Hallo Norbert,
deine Darstellung ist leider falsch.
Du glättest die Messdaten in einer Nachbereitung, wenn alle Daten statisch vorliegen, d.h. wenn der Messprozess abgeschlossen ist. So hast Du scheinbar Zugriff auf Messpunkte, die auch in der Zukunft vom gerade betrachteten Wert aus liegen.
Hier liegt aber ein Messprozess in Echtzeit vor, bei dem Du nur Werte aus der Vergangenheit in deine "Formel" einberechnen kannst. Außerdem verwendest Du (zufällig) ebenfalls 19 Koeffizienten wie ich bei meinem FIR-Filter.
Ein FIR-Filter hat klar definierte Eigenschaften, die ich beim Entwurf vorgeben kann.
Meine Filter-Implementierung auf dem Mikrokontroller, der direkt den Sensor ausliest, benutzt ausschließlich
die Integer-Operationen für Summe und Produkt. Und das mit Koeffizienten für die sogenannte "Q.15"-Darstellung, welche für den verwendeten Mikrokontroller optimiert ist.
(Für Interessierte: http://sestevenson.wordpress.com/introduction-to-fixed-point-representation/)
Im übrigen habe ich in meinen vorigen Beiträgen stets davon gesprochen, daß ich direkt den Messprozess im Mikrokontroller beeinflussen werde, d.h. die sample-time wird dort bei etwa 20ms liegen, im Gegensatz zu den 100 bis 200 ms der Telemetrieübertragung in die Taranis (siehe post #35).
Im untenstehenden Diagramm habe ich das, was "Norbert eigentlich macht" und das "was Tempo macht" gegenübergestellt. So, lieber Norbert, muß ich Dir leider in all Deinen oben gemachten Aussagen widersprechen:
Hallo Norbert,
deine Darstellung ist leider falsch.
Du glättest die Messdaten in einer Nachbereitung, wenn alle Daten statisch vorliegen, d.h. wenn der Messprozess abgeschlossen ist. So hast Du scheinbar Zugriff auf Messpunkte, die auch in der Zukunft vom gerade betrachteten Wert aus liegen.
Hier liegt aber ein Messprozess in Echtzeit vor, bei dem Du nur Werte aus der Vergangenheit in deine "Formel" einberechnen kannst. Außerdem verwendest Du (zufällig) ebenfalls 19 Koeffizienten wie ich bei meinem FIR-Filter.
Ein FIR-Filter hat klar definierte Eigenschaften, die ich beim Entwurf vorgeben kann.
Meine Filter-Implementierung auf dem Mikrokontroller, der direkt den Sensor ausliest, benutzt ausschließlich
die Integer-Operationen für Summe und Produkt. Und das mit Koeffizienten für die sogenannte "Q.15"-Darstellung, welche für den verwendeten Mikrokontroller optimiert ist.
(Für Interessierte: http://sestevenson.wordpress.com/introduction-to-fixed-point-representation/)
Im übrigen habe ich in meinen vorigen Beiträgen stets davon gesprochen, daß ich direkt den Messprozess im Mikrokontroller beeinflussen werde, d.h. die sample-time wird dort bei etwa 20ms liegen, im Gegensatz zu den 100 bis 200 ms der Telemetrieübertragung in die Taranis (siehe post #35).
Im untenstehenden Diagramm habe ich das, was "Norbert eigentlich macht" und das "was Tempo macht" gegenübergestellt. So, lieber Norbert, muß ich Dir leider in all Deinen oben gemachten Aussagen widersprechen:
Beispiel für Datenglättung mit Filter- Teil 3
Nach der Vorstellung verschiedener FIR-Filter zur Datenglättung nun der Kalman-Filter in seiner einfachsten Form.
(Für Interessierte: http://interactive-matter.eu/blog/2009/12/18/filtering-sensor-data-with-a-kalman-filter/ )
Im Vergleich zu den FIR-Filtern kann der Kalman-Filter "schnell" sein. Aber er deformiert den Kurvenverlauf sichtbar.
Wählt man Parameter, die dem Kurvenverlauf besser folgen, so wird die Ableitung für ein Variometersignal ungünstiger.
Die FIR-Filter sind deutlich glatter, folgen gut dem Verlauf der Messwerte, aber hinken zeitlich hinterher.
Nun genug der vorliegenden Treppenstufen-Messung, bei der "in der Taranis nur alle 200ms Höhenmesswerte aufgezeichnet wurden".
Als nächstes werde ich direkt mit dem Höhensensor MS5611 arbeiten und die Höhenmessersignale in Echtzeit
in Variometersignale wandeln.
Nach der Vorstellung verschiedener FIR-Filter zur Datenglättung nun der Kalman-Filter in seiner einfachsten Form.
(Für Interessierte: http://interactive-matter.eu/blog/2009/12/18/filtering-sensor-data-with-a-kalman-filter/ )
Im Vergleich zu den FIR-Filtern kann der Kalman-Filter "schnell" sein. Aber er deformiert den Kurvenverlauf sichtbar.
Wählt man Parameter, die dem Kurvenverlauf besser folgen, so wird die Ableitung für ein Variometersignal ungünstiger.
Die FIR-Filter sind deutlich glatter, folgen gut dem Verlauf der Messwerte, aber hinken zeitlich hinterher.
Nun genug der vorliegenden Treppenstufen-Messung, bei der "in der Taranis nur alle 200ms Höhenmesswerte aufgezeichnet wurden".
Als nächstes werde ich direkt mit dem Höhensensor MS5611 arbeiten und die Höhenmessersignale in Echtzeit
in Variometersignale wandeln.
Hallo Tempo,
vielen Dank für deine Darstellung. Du hast selbstverständlich recht mit der zeitlichen Verzögerung. Ich kann natürlich nur Signale verarbeiten, wenn sie bereits vorliegen. Dh bei 19 samples habe ich 9 samples Verzögerung, wie du darstellst. Meine Einwendung betraf auch den FIR Filter 38 Ordnung, der erhebliche Überschwinger produziert und eine deutlich grössere Verzögerung.
Ebenso wiederspreche ich nicht deiner Darstellung, dass man in Realtime, der samplezeit des Höhenmesser arbeiten sollte.
Meine Einwendung betraf die deutlich komplexere Berechnung mit FIR Filtern, bei denen ich nicht sicher bin, ob die verwendeten Microcontroller das in Echtzeit schaffen. Die berechneten Ergebnisse sind ja sehr ähnlich.
Vielen Dank für die Darstellung des Kalman-Filters. Wie du schreibst, ist die Verzögerung deutlich geringer. Er reduziert auch das Rauschen deutlich und nimmt die Ausreisser raus. In relation zur Verzögerung des FIR Filters finde ich das Ergebnis besser, auch wenn es nicht so stetig ist. das lässt sich aber sicher durch Filterung des abgeleiteten Variosignal hinbekommen.
vielen Dank für deine Darstellung. Du hast selbstverständlich recht mit der zeitlichen Verzögerung. Ich kann natürlich nur Signale verarbeiten, wenn sie bereits vorliegen. Dh bei 19 samples habe ich 9 samples Verzögerung, wie du darstellst. Meine Einwendung betraf auch den FIR Filter 38 Ordnung, der erhebliche Überschwinger produziert und eine deutlich grössere Verzögerung.
Ebenso wiederspreche ich nicht deiner Darstellung, dass man in Realtime, der samplezeit des Höhenmesser arbeiten sollte.
Meine Einwendung betraf die deutlich komplexere Berechnung mit FIR Filtern, bei denen ich nicht sicher bin, ob die verwendeten Microcontroller das in Echtzeit schaffen. Die berechneten Ergebnisse sind ja sehr ähnlich.
Vielen Dank für die Darstellung des Kalman-Filters. Wie du schreibst, ist die Verzögerung deutlich geringer. Er reduziert auch das Rauschen deutlich und nimmt die Ausreisser raus. In relation zur Verzögerung des FIR Filters finde ich das Ergebnis besser, auch wenn es nicht so stetig ist. das lässt sich aber sicher durch Filterung des abgeleiteten Variosignal hinbekommen.
Rechenzeit für Filter auf ATmega328
Zur Information:
Eine FIR-Filterberechnung mit 15 Koeffizienten und Berechnung im Q.15-Format (Integer-Rechnungen) braucht z.B. auf einem ATmega328 (ein 8Bit-Mikrokontroller mit 16MHz-Takt) rund 0,000430sec=430Mikrosekunden.
Diese Berechnung geht z.B. 20 mal schneller als ein Drucksensor Zeit braucht, wenn er z.B. alle 8ms einen Messwert ausgibt.
Zum Vergleich ist auf der FVAS-02H Platine ein 32Bit-Mikrokontroller(STM32F), der darüberhinaus noch viel schneller getaktet ist. Und der macht dann Filterberechnungen in der Zeit von rund "o,nix"
Die Chinesen von FrSky haben zwar eine billige Hardware im Angebot, aber bis jetzt fehlt eine intelligente Software für eine Variometerfunktion.
@norbert
Deine Glättungsberechnung ist identisch zu einer FIR-Filterberechnung, denn Du hast auch ein FIR-Filter berechnet, allerdings mit "handgemachten Eigenschaften" !
In meinem Falle habe ich den Datensatz für die Koeffizienten definiert nach meinen Anforderungen bezüglich Frequenzunterdrückung ausgelegt.
Bei der Implementierung auf einem Mikrokontroller lassen sich Optimierungen machen, wie z.B. mit den obenangeführten Q.15-Zahlen.
Zur Information:
Eine FIR-Filterberechnung mit 15 Koeffizienten und Berechnung im Q.15-Format (Integer-Rechnungen) braucht z.B. auf einem ATmega328 (ein 8Bit-Mikrokontroller mit 16MHz-Takt) rund 0,000430sec=430Mikrosekunden.
Diese Berechnung geht z.B. 20 mal schneller als ein Drucksensor Zeit braucht, wenn er z.B. alle 8ms einen Messwert ausgibt.
Zum Vergleich ist auf der FVAS-02H Platine ein 32Bit-Mikrokontroller(STM32F), der darüberhinaus noch viel schneller getaktet ist. Und der macht dann Filterberechnungen in der Zeit von rund "o,nix"
Die Chinesen von FrSky haben zwar eine billige Hardware im Angebot, aber bis jetzt fehlt eine intelligente Software für eine Variometerfunktion.
@norbert
Deine Glättungsberechnung ist identisch zu einer FIR-Filterberechnung, denn Du hast auch ein FIR-Filter berechnet, allerdings mit "handgemachten Eigenschaften" !
In meinem Falle habe ich den Datensatz für die Koeffizienten definiert nach meinen Anforderungen bezüglich Frequenzunterdrückung ausgelegt.
Bei der Implementierung auf einem Mikrokontroller lassen sich Optimierungen machen, wie z.B. mit den obenangeführten Q.15-Zahlen.
Zuletzt bearbeitet:
Hallo,
habe heute mein Vario bekommen.
Am X8R angeklemmt, am Sender im Telemetriereiter alle möglichen Anzeigen die mit Höhe zu tun haben eingestellt, und ich bekomme keine Werte angezeigt. Die LED am Vario blinkt. Welche Funktion hat die LED, werden da auch Statusmeldungen ausgegeben?
Hat jemand von euch eine Idee was da nicht so sein könnte wie es sein sollte?
Bin etwas ratlos.
Claudio
habe heute mein Vario bekommen.
Am X8R angeklemmt, am Sender im Telemetriereiter alle möglichen Anzeigen die mit Höhe zu tun haben eingestellt, und ich bekomme keine Werte angezeigt. Die LED am Vario blinkt. Welche Funktion hat die LED, werden da auch Statusmeldungen ausgegeben?
Hat jemand von euch eine Idee was da nicht so sein könnte wie es sein sollte?
Bin etwas ratlos.
Claudio
Zuletzt bearbeitet:
Danke Tempo für die Klarstellung. Dann steht einer FIR Filterberechnung nichts im Weg, da die Koeffizientenanpassung da wesentlich einfacher unf flexibler ist als das Ändern der diskreten Werte.
Die "handgemachten Eigenschaften" sind natürlich kein Zufall. Sie entsprechen der Hüllkurve eines Filters. Dieser Filtertyp sollte eben keine Überschwinger erzeugen. Die Koeffizienten habe ich aber nicht asugerechnet sondern aus dem Gedächnis gewählt.
Dann werde ich noch FrSky versuchen zu überzeugen, dass sie ihre Variofunktion überarbeiten. Habe gestern noch das älteste Vario auf die aktuelle Firmware gebracht und dann digitale und analoge Varioausgabe gegenüber gestellt. In der Tendenz das selbe unbefriedigende Ergebnis.
Die "handgemachten Eigenschaften" sind natürlich kein Zufall. Sie entsprechen der Hüllkurve eines Filters. Dieser Filtertyp sollte eben keine Überschwinger erzeugen. Die Koeffizienten habe ich aber nicht asugerechnet sondern aus dem Gedächnis gewählt.
Dann werde ich noch FrSky versuchen zu überzeugen, dass sie ihre Variofunktion überarbeiten. Habe gestern noch das älteste Vario auf die aktuelle Firmware gebracht und dann digitale und analoge Varioausgabe gegenüber gestellt. In der Tendenz das selbe unbefriedigende Ergebnis.
@Tempo,
wie angekündigt, werde ich mich bezüglich des Vario an FrSky wenden. Ich überlege ebenfalls unsere Erfahrungen in internationale Foren zu stellen, in der Hoffnung, dass das hilft FrSky zu bewegen, etwas zu tun.
Meine Frage lautet: Darf ich deine Erkenntnisse und Grafiken zur Untermauerung des Sachverhaltes verwenden?
mfG
Norbert
wie angekündigt, werde ich mich bezüglich des Vario an FrSky wenden. Ich überlege ebenfalls unsere Erfahrungen in internationale Foren zu stellen, in der Hoffnung, dass das hilft FrSky zu bewegen, etwas zu tun.
Meine Frage lautet: Darf ich deine Erkenntnisse und Grafiken zur Untermauerung des Sachverhaltes verwenden?
mfG
Norbert
Moin Norbert,
finde ich gut was Ihr da macht. FrSky hat ja nun selber bei der Taranis gesehen, wie gut es ist mit OpenSource und der Gemeinde zusammen zu arbeiten. Da wohl FrSky je Menge diesbezüglicher Ratschläge und Anfragen per E-Mail bekommt möchte ich vorschlagen hier @Helle zu fragen ob er nicht besonders guten Kontakt oder besonders gute Kanäle zu FrSky hat. Da könnte Deine Anfrage eventuell wirkungsvoller sein.
Ich kann mir nicht vorstellen, das FrSky irgend einen Grund hat, die Vario-Software nicht freizugeben, da ja bereits die Software der Taranis auch schon für Jederman oder Firma zugänglich ist.
LG
Perry
finde ich gut was Ihr da macht. FrSky hat ja nun selber bei der Taranis gesehen, wie gut es ist mit OpenSource und der Gemeinde zusammen zu arbeiten. Da wohl FrSky je Menge diesbezüglicher Ratschläge und Anfragen per E-Mail bekommt möchte ich vorschlagen hier @Helle zu fragen ob er nicht besonders guten Kontakt oder besonders gute Kanäle zu FrSky hat. Da könnte Deine Anfrage eventuell wirkungsvoller sein.
Ich kann mir nicht vorstellen, das FrSky irgend einen Grund hat, die Vario-Software nicht freizugeben, da ja bereits die Software der Taranis auch schon für Jederman oder Firma zugänglich ist.
LG
Perry
- Status
