Einer der schönsten Modellflughänge
die ich kenne: Der Kanonensattel südlich der Alp Flix, Graubünden, Schweiz.
©2007 Helmut Stettmaier
⇒IndexFlugmodell-Elektronik⇒special: Render-Engine⇒anderes die PareNeira bei der AlpFlix
Drucksensor MS5803 - Rauschen, Lageempfindlichkeit16. März. 2015
Drucksensor MS5803 -
Lageempfindlichkeit

Der genannte ↠Drucksensor der Firma Measurements Specialities kann mit exzellenter Empfindlichkeit und geringem Rauschen aufwarten. Das Rauschen ist noch geringer als das des sonst verwendeten MS5611 (aus gleichem Hause) allerdings beeinflusst das Gel (der "Glibber":-) das Messergebnis durch sein Gewicht. Die Graphik zeigt aufgezeichnete Druckwerte je nach Lage des Sensors: Links beginnt die Aufzeichnung mit der Symmetrie-Achse des Sensors waagerecht (im Folgenden "liegend"), dann wird der "Topf" zwei mal nach unten und nach oben gerichtet, anschließend der Sensor mit dem "Topf" nach oben geschüttelt (nicht gerührt) und anschließend wieder mit liegender Ausrichtung geschüttelt und still gehalten. Die Ordinate ist in 10-Pa-Schritten eingeteilt. Wenn man die beiden Ausrichtungen "Topf nach oben" und "Topf nach unten" mit +1g und -1g bewertet zeigt diese einzelne Auswertung, dass 1g Beschleunigung zu etwa 10 Pa und zwischen 0,8 und 1,2 m Höhenfehler führt. Das unpräzise Schütteln hat offenbar etwa ±1g erzeugt. Bei liegend ausgerichtetem Sensor verringert sich der Fehler auf etwa ¼. Die gemessenen Drücke sind bei den 3 angegebenen Lagen nicht symmetrisch wie man gerne annehmen möchte - der Glibber drückt also auch bei liegender Montage ein wenig auf die Membran. Da kann man natürlich nach dem "optimalen" Winkel für die Ausrichtung suchen (leicht mit dem Topf nach unten geneigt), aber das erspare ich mir (und Ihnen).

Drucksensor MS5803 - Rauschen

Es dürfte klar werden, dass der Sensor in einem Modellflug-Variometer nur brauchbar ist wenn er liegend ausgerichtet wird - auch dann bleibt er nicht völlig frei von g-Einflüssen, allerdings darf man das Schütteln nicht als "Standard-Anwendungsfall" betrachten. Eine andauernde nennens- werte g-Belastung dürfte sich nur im Abfangbogen einstellen, dabei ist aber ein Höhenfehler in der Größenordnung von wenigen -zig Zentimetern tolerierbar. Das Rauschen ist entsprechend heutiger Massstäbe erfreu- lich gering wie im 2.Bild zu erkennen ist - die Ordinate ist in 1-Pa-Schritten markiert; die Standard-Abweichung (sofern man bei so grob gerasterten Werten mit diesem Begriff hantieren darf) liegt sehr nahe bei 1 Pa.

Drucksensor MS5803 - Rauschen

Die bei anderen Sensoren unangenehme Drift kurz nach dem Einschal- ten ist beim MS5803 nur sehr geringfügig ausgeprägt: Das 3. Bild zeigt die Auswertung für ein einziges Exemplar; die linke Ordinate ist wieder der Druck in 5-Pa-Schritten, die rechte Ordinate die Temperatur in 0,2°-Schritten von 24°C bis gut 25°C und die Abszisse gibt für jeden Tick 200 Messungen, also 5 Sekunden wieder. Es ist erkennbar dass der Sensor nach 5 Sekunden stabil war - da kommt der MS5611 nicht mit. Update: Ingo Stahl berichtet von MS5611-Exemplaren in seinem Besitz die ebenfalls nach sehr kurzer Zeit stabil sind. Auch dieser Sensor ist lichtempfindlich, mit einer simplen winzigen Leuchtdioden-Lampe konnte ich das Ding um 5m abstürzen lassen...

Drucksensor MS5803 - Das kann man löten...

Als Vorteile darf man also anführen: Etwas geringeres Rauschen als beim MS5611, geringere Drift und für den Bastler mit nur einem Fein-Lötkolben lötbar. (Das 4. Bild zeigt eine nicht besonders schöne aber funktionierende Bedrahtung, dabei ist das Protokoll auf I²C und die Adresse auf 0xee eingestellt). Nachteile: Mehr Platzbedarf, Lageab- hängigkeit.

Druckmessung, Glättung der Höhe-Werte, hochauflösende Höhenanzeige11. Jan. 2015
Druckmessung, Glättung der
Höhe-Werte
Druckmessung, Glättung der Höhe-Werte (PC-Simulation)

Im Bild sind 3 Datenströme dar- gestellt:
(a) Messwerte aus dem Druck- sensor MS5611,
(b) mittels Vorfilterung und Aus- gleichsrechnung geglättete Höhe- Werte und
(c) mittels modifizierter Rundung nachgefilterte Höhen.

Die Abszisse ist in Millisekunden angegeben, die linke Ordinate be- zeichnet die gemessenen Drücke - da der Druck mit der Höhe sinkt ist die Skala "verkehrt herum". Die rechte Ordinate gibt die bei Stan- dard-Wetterbedingungen zugehö- rige Höhe über NN an.

Zu (a): Die kleinen Kreuzchen zeigen die 40 Messungen pro Sekunde, die im "empfindlichsten" Modus mit der Oversampling-Rate 4096 erfasst wurden. Das Rauschen ist durch eine Standard-Abweichung von ca. 2 Pa gekennzeichnet, es kommen also "immer wieder mal" Messungen mit 4 Pa Abweichung (und selten sogar mehr) vor.

Zu (b): Vorfilterung und Ausgleichsrechnung sind die gleichen wie im Aufsatz unten angegeben, allerdings interessieren hier nur die Höhen-Ergebnisse. Die schwarze Kurve zeigt die Höhen an.

Zu (c): Die Ergebnisse der Ausgleichsrechnung täuschen eine Genauigkeit vor, die nun doch nicht erreichbar ist - sie müssen auf eine nicht zu viel versprechende "offizielle" Auflösung gerundet werden: Es wird eine Auflösung von 10 cm/Schritt festgelegt. Eine "korrekte" Rundung verläuft so: Wenn die erste wegzurundende Stelle >=5 ist wird aufgerundet (von 0 weg), sonst abgerundet (zu 0 hin - diese Formulierung stimmt dann auch bei negativen Zahlen). Das führt zu Oszillationen wenn die wegzurundende Stelle in der Nähe von 5 "rumeiert" - im Bild könnte das bei Sekunde 156,5 der Fall sein. Nun kann man den "Fangbereich" des zuletzt ausgegebenen Wertes ein wenig vergrößern: Aufrunden ab 3 und abrunden bis 7. Das ist z.B. bei Sekunde 156,5 und auch 154,8 passiert. Dadurch wird das Oszillieren weitgehend vermieden, das Filter bewirkt bei großen Änderungen - wunschgemäß - nichts und es wird in Kauf genommen, dass die ausgegebenen Werte des lieben Friedens halber (also kein "Jitter") schon mal um max. 2 Zentimeter daneben liegen.

Die Daten geben einen Ausschnitt aus einem Flug wieder: Ein Ansteigen um gut 30 cm, dann Höhe halten über ca. 3 Sekunden und zuletzt wieder ein etwas schwächerer Anstieg mit etwa 0.3 m/Sek. - eine Herausforderung an jedes Variometer, so etwas "schnell", "angenehm" und "möglichst richtig" anzugeben. Ich sehe eine Lösung darin, die Höhe anzuzeigen anstelle des Steigens. Vorteile:

Problem: Wie bringt man ca. 3000 "befliegbare" Meter Höhe mit einer Auflösung von 10cm/Schritt in einer beschränkten Anzeige unter? Da lassen wir uns von der Uhr (und natürlich auch den alten, mechanischen Höhenanzeigen in der Luftfahrt) inspirieren: Der große Zeiger rennt viel zu schnell 'rum, seine Anzeige ist genau aber nicht eindeutig. Wer Eindeutigkeit braucht muss auf den kleinen Zieger sehen. Wenn dies nicht reicht kann man es nach oben um den Kalender und nach unten um den Sekundenzeiger ergänzen.

Einfache hochauflösende
Höhen-Anzeigen

Rechts ist eine 16-Segment-Anzeige zu sehen, in der die inneren Segmente die Rolle des großen Zeigers übernehmen, die äusseren Segmente in etwa die Rolle des kleinen Zeigers. Nach einer kompletten Umdrehung des "großen" Zeigers (8 Schritte) bewegt sich die Anzeige am Rand um eine Stufe. Damit kann man also 64 verschiedene Höhen anzeigen bevor sich alles wiederholt - für eine Höhenanzeige zum Zweck der Erkennung Steigen/Sinken reicht das aus: 2-3 m/s Steigen sind genau anzeigbar in der oben angegebenen Auflösung. Diese Anzeige ist natürlich sehr primitiv und bestenfalls für eine Machbarkeitsstudie geeignet, niemand wird damit ernsthaft zum Fliegen gehen wollen.
Die andere Anzeige (2 kaskadierte 7·5-LED-Matrizen) ist aufwändiger, sicherlich aber auch informativer und vielleicht sogar angenehmer. Die zwei Balken übernehmen die Anzeige eines Höhen-Bereiches in verschiedenen Feinheiten: 10·0,1m und 10·1m. Auch bei diesen sehr primitiven Anzeigen sind sicher noch Verbesserungen denkbar, z.B. durch fließendere Übergänge. Es soll jetzt auch hier nicht diskutiert werden, wie solche Anzeigen so im Blickfeld des Piloten positioniert werden können, so dass sie bequem ablesbar sind.
Natürlich denkt man jetzt auch an die Google-Brille und stellt sich eine Höhen-Kurve vor, so wie sie aus einem Kurvenschreiber kommen könnte... Aber das werde ich hier nur kurz streifen: Google-Glass ist für Telemetrie-Anzeigen beim Betrieb von Modellflugzeugen sicherlich ungeeignet - das Bild wird oben-rechts eingeblendet, in einem Bereich des Sichtfeldes das für das Flugmodell reserviert bleiben muss und wo der Hintergrund (Himmel) am hellsten ist und die Leuchtstärke der Anzeige reicht ganz bestimmt nicht aus. Ebenso ist die angegebene Akku-Kapazität bzw. Laufzeit zu gering. Andere Datenbrillen, die besonders für Sport-Anwendungen beworben werden, könnten vielleicht etwas geeigneter sein wenn sie das Bild am unteren Rand des Sichtfeldes einblenden und deutlich stärkere Akkus haben, aber sie werden wohl noch ein wenig auf sich warten lassen und die Preise sind sehr hoch.

Ich habe die optischen Anzeigen erwähnt weil sie in einer Webseite leicht anzuzeigen sind und vielleicht einmal später gut machbar sein werden. Stand der Technik ist allerdings die akustische Anzeige: Vario-Ton und Sprachausgabe. Nochmal die Frage: Wie bringt man ca. 3000 "befliegbare" Meter Höhe mit einer Auflösung von 10cm/Schritt im hörbaren Tonbereich unter? Auch hier gibt es eine Lösung, bei der durch zyklische Wiederholungen die Höhe in "handliche" vertikale "Streifen" unterteilt wird - man kann einmal mit dem Stichwort "shepard tone" googeln gehen: Wenn der Ton den vorgesehenen Bereich nach oben verlässt wird er ausgeblendet und in (scheinbar) gleicher Höhe eine Oktave tiefer fließend und überlagernd eingeblendet.

Audio-Anzeige Steigen (wie oben)

Die Sound-Datei gibt wieder, wie sich ein geringes Steigen, mit einer Auf-/Abbewegung überlagert, anhören könnte (falls der Browser die Datei nicht abspielen will: Bitte die Datei mauell ⇒fclimb.wav laden). Die Stufen, die im Ton zu hören sind, kommen daher dass die (simulierte) Höhe nur 10 mal pro Sekunde neu berechnet wurde (Die Telemetrie z.B. des MLink®-Systemes überträgt nicht schneller). Die vom Tongenerator erzeugbaren Töne unterscheiden sich so wenig, dass ich sie nur mit Mühe auseinander halten kann: 32 Töne gleichmäßig über eine Oktave verteilt, also sind die "Streifen", in die die Höhe unterteilt wird, 3,2 m hoch. Es besteht kein Zweifel daran, dass es hier Potenzial für weitere Verbesserungen gibt, aber einem "konventionellen" Vario-Ton hätte man kaum angemerkt, dass hier eine Aufwärts-Bewegung simuliert wurde, denn die Auf-/Abbewegungen überdecken das geringe Steigen fast vollständig. Mit etwas Übung könnte man mit so einer akustischen Anzeige gut zurecht kommen.Sicherlich wird das Optimum aus 2 verschiedenen Anzeigen bestehen: Bei kleinen Höhenänderungen der hier besprochenen Höhenanzeige, ab 1 oder 2 m/s Steigen dem konventionellen Vario-Ton, der beim Zentrieren eines ausgeprägteren Bartes wohl nützlicher ist.

Nachtrag: TEK ist selbstverständlich in allen Varianten möglich:

Mehr zur Erfassung von Druck (Höhe) und Druckänderung (Steigwert)Dez. 2014
Druckmessung, Ausgleichspolynom, Glättung und
Druckänderung mit der Zeit
Druckmessung, Ausgleichspolynom, Glättung und Druckänderung mit der Zeit (PC-Sim.)

Das Bild zeigt die Vorgehens- weise der Rauschfilterung im neuen Variometer.
Die Kreuzchen sind gemessene Druckwerte, die Realität mit der wir umgehen müssen. Die durch- gezogene Linie ist das Ergebnis einer sanften (:-) Vorfilterung, in der neben einer Kompaktifizierung 4:1 der Daten auch die extremen Messwert-Ausreisser gekappt werden.
Die kleinen schwarzen Quatrate sind Druckwerte nach der Aus- gleichsrechnung und die "Fähn- chen", die von den geglätteten Druckwerten nach links wegge- hen, stellen die zeitliche Ände- rung des Druckes an der ent- sprechenden Stelle dar.
Dies ist die in der numerischen Mathematik (dringendst) empfohlene Rechnung: Berechne eine beherrschbare Kurve so, dass sie im gewählten Ausschnitt möglichst gut, d.h. mit minimaler Fehlerquadrat-Summe, zu den Daten passt. Wenn du die Ableitung nach der Zeit brauchst (in den Steigwert umzurechnen) dann differenziere diese Kurve, bilde niemals Differenzen aus verrauschten Messwerten. Die beherrschbare Kurve ist für einen Zeitpunkt als graue Kurve dargestellt, sie wird für jeden Zeitpunkt, für den der Steigwert abgefragt wird (also ca. 10 mal pro Sekunde) extra berechnet. Es gibt ein paar wohl bekannte Tricks, den Rechenaufwand in Grenzen zu halten und das ist ja ein Großteil vom Spaß an der Sache. Erschwerend wirkt allerdings, dass für die Berechnung der Kurve nur Messwerte links vom augenblicklichen Messwert ("jetzt" und in der Vergangenheit) zur Verfügung stehen; das zu berücksichtigen macht den Spaß nur größer... Die graue Kurve im Bild wurde für den Zeitpunkt an ihrem rechten Ende berechnet. Wer das alles genauer wissen will kann sich den Aufsatz
⇒"Zur Filterung von Drucksensor-Daten" antun.

Dies ist die beste Methode, die mit einfachen Mitteln zum Ziel führt, aber sie ist nicht fehlerfrei: Im Bild sieht man z.B. wie die Berechnung der Druckänderung im letzten Drittel des dargestellten Bereiches der tatsächlichen Entwicklung hinterher läuft. Das Haupt-Problem ist auch hier, dass die Druckwerte geglättet werden obwohl die Druckänderungen gesucht sind. Hier wird zwar auf relativ hohem Niveau gejammert, das Problem ist gegenüber den Mittelwert-Filtern zwar gut verringert und nicht wirklich abgeschafft.

Das mit diesem erheblichen Aufwand erzeugte Vario-Signal ist "schneller" als das, was man derzeit (2014) zu kaufen bekommt. Ob "schneller" auch "besser" ist muss jeder für sich selbst entscheiden. Ein "langsames" Variometer mittelt kurze, evtl. heftige Bewegungen aus: Es zeigt das heftige Steigen nur sehr gering an, dafür aber über einen größeren Zeitraum. Wenn man mit einem 4m-Segler weit draußen über dem Tal nach Aufwind-Feldern sucht kann das das richtige sein. Ein (sehr) "schnelles" Vario gibt auch kurze Höhen-Impulse mit den angenähert "richtigen" Steigwerten an, was oft zu heftigem Gezirpe führt - andererseits kann man enge Bärte damit lokalisieren, denn wenn das Modell steigt pfeift auch das Variometer höher, und zwar sofort und nicht zu lang. Beim Umstieg auf so ein schnelles Variometer wird man vielleicht den Wunsch haben, die Steigwerte mit geringeren Tonhöhen anzuzeigen.

Besser (richtig gut) sieht es hingegen bei den Druckwerten aus: Sie folgen der gefühlten Mitte der Datenwolke praktisch ohne Verzögerung und mit erstaunlicher Genauigkeit und Glättung, mit einer geringfügigen Nachfilterung können glatte, weitestgehend wahre und aktuelle Höhen-Kurven mit einer Auflösung von 10cm errechnet werden (1 Pa, die Auflösung des Sensors - siehe Zeilen im Bild - entsprechen etwa 8-12cm Höhendifferenz). Hallo! 10cm Auflösung!! Diese Fakten bringen mich ins Grübeln: Kann man aus der Not eine Tugend machen und anstelle des Steigwertes die - hochaufgelöste - Höhe dem Modellpiloten mitteilen? Dazu im nächsten Aufsatz (also weiter oben) mehr.

Nachtrag: Es gab eine Nachfrage ob das mit einem "XMEGA" umsetzbar sei. Grundsätzlich ist zu sagen, dass die Routinen zur Rauschfilterung der Druckwerte ausschließlich von der verwendeten MCU durchgeführt werden (keine besondere periphere Hardware erforderlich) und solange die Rechenleistung ausreicht ist jede MCU verwendbar. Es sind für jede Abfrage eines Höhen-/ Variowertes zusammen etwa folgende Aufwände zu kalkulieren:

Der Bedarf an RAM-Speicher ist unkritisch.
Der gesamte Anteil dieser Rechnungen sollte 50% der Rechenzeit nicht übersteigen, denn das Gerät soll ja auch noch was anderes machen (können), das muss jeder Designer mit sich selbst abmachen. Wenn man z.B. auch noch eine Geschwindigkeitsmessung und -Auswertung sowie die dann fällige TEK-Rechnung machen will sollte man grob mit dem doppeltem Aufwand rechnen (obwohl an die Glättung für die Drücke des Differenzdrucksensors nicht so hohe Anforderungen zu stellen sind, denn die Fluggeschwindigkeit ist "vorhersehbarer" und damit mit steiferen Ausgleischskurven und weniger Stützstellen aufzubereiten). "Mein" LPC812 ist trotz der bescheidenen Taktung damit dann nicht überfordert.

Diese Software gebe ich jedem interessierten Bastler weiter, ich biete sie jedoch nicht "anonym" zum Download an. Wer sich dafür interessiert meldet sich bei mir und bekommt die Quellen unter LPGL-Bedingungen (inclusive Unterstützung). Bei dem sicherlich geringen öffentlichen Interesse ist dies die sinnvollste LGPL-Auslegung.

Ein verbessertes Modellflug-VariometerRückblick 2013, 2014
Prototyp Variometer
Prototyp Variometer

Es gibt reichlich Modellflug-Variometer zu kaufen und auch Selbstbau-Projekte sind zahlreich. Warum also noch eins?

Derzeit erhältliche Modellbau-Variometer bestehen aus einem Absolutdruck-Sensor, einer Auswertesoftware in einem - üblicherweise - 8-Bit-Microcontroller und einer Protokoll-Schnittstelle zum jeweiligen RC-Empfänger bzw. zur Telemetriezentrale im Modell.
Zum Einsatz kommen kaum noch analoge Drucksensoren, fast ausschließlich die mit einer I²C-Schnittstelle ausgestatteten
⇒Bosch-BMP085 und vor allem der ⇒MEAS-Sensor MS5611. Für beide Sensoren gibt es inzwischen Nachfolger im jeweiligen Hause. Diese Sensoren sind sehr einfach einsetzbar, der Microcontroller braucht nur eine I²C- aber keine analoge Schnittstelle. Alle mir bekannten Modellflug-Variometer und -Altimeter verwenden Absolut-Drucksensoren, die also den ganzen Druck zwischen (fast) Vakuum und dem atmosphärischen Druck in Meereshöhe messen - diese werden am Rande ihrer technischen Möglichkeiten betrieben: So ein Drucksensor muss in wenigen -zig Millionsteln des Messbereiches noch "vernünftige" Werte liefern - und das bei geringsten Abmessungen und minimalem Stromverbrauch... noch ein Wunsch? Ach ja, kosten soll er auch noch so gut wie nichts. Das war vor wenigen Jahren noch nicht möglich und auch heute noch hat man einen "technischen" Preis zu bezahlen:

Drucksensoren haben ein deutlich größeres Eigenrauschen als die geforderte Auflösung der Druckwerte (MS5611: Standardabweichung ca. 1,5 bis 2 Pa unter günstigsten Bedingungen), so dass eine aufwändige Rauschfilterung angewandt werden muss. Analoge Drucksensoren erlauben eine analog-elektronische Filterung, die früher sehr effizient eingesetzt wurde aber heutzutage muss es ja digital sein. Die in den mir bekannten Modellflug-Variometern eingesetzten Filter beruhen alle im weitesten Sinne auf der Durchschnitt-Bildung. Diese Methode hat einen wesentlichen Vorteil: Sie ist so einfach dass man sie auf kleinen, wenig leistungsfähigen Microcontrollern implementieren kann. Der Nachteil ist jedoch erheblich: Man muss eine große Menge von Messwerten mitteln um das Rauschen in einen erträglichen Bereich zu bringen. Die digitalen Sensoren liefern aber nur eine begrenzte Anzahl von Messwerten pro Sekunde (MS5611: ca. 40 Messungen pro Sekunde wenn das oben angegebene Rauschen eingehalten werden soll) und die zur Mittelung herangezogenen Messungen verteilen sich über einen weiten Zeitraum. Beim ⇒Multiplex-Variometer ist dieser Zeitraum einstellbar und man kann die Auswirkungen der verschieden langen "Integrationsintervalle" experimentell studieren. Leider bewirkt die Mittelung über "viele" Messwerte eine unerwünschte Zeitverzögerung des Ergebnisses - wenn man z.B. für die Mittelung die Werte über 2 Sekunden heranzieht dann bekommt man ein Ergebnis, dass, vereinfacht, irgendwann wohl in diesen 2 Sekunden gültig war. Wer ein großes Modell weit draussen über dem Tal fliegen lässt mag damit zufrieden sein; wer aber, wie ich, kleine Segler in engen Räumen betreibt ist auf rasche Informationen angewiesen. Es ist schon ein wenig spaßig: Der erste, der mit seinem (mir unbekannten) Filter ein klein wenig "schnellere" Ergebnisse bekam, sprach sofort in der Werbung darüber ("...da ist man durch den Bart durch bevor man's merkt..." oder so ähnlich). Vorher war das Thema unwichtig. Auch in der manntragenden Segelfliegerei spricht man von einer "Zeitkonstante" des Varios, aber ich will darüber nichts sagen, denn ich habe andere Randbedingungen.

Ich erinnerte mich nun an das, was ich vor mehr als 40 Jahren im 3. Semester in der Vorlesung "Numerische Mathematik I" gelernt hatte, machte mich mit einem der inzwischen erhältlichen klein-aber-oho-Microcontrollern vertraut und baute ein Variometer mit einer Standard-Filterung namens "Lineare Ausgleichsrechnung". Ich erhoffte mir eine deutlich schnellere und in der Glättungsleistung mindestens gleichwertige Rauschfilterung und kann nach einer ersten Erprobung während der Saison 2014 sagen, dass das Ziel erreicht wurde.

Das Gerät basiert auf einem LPC812-Microcontroller - ich wurde auch nach den Gründen für die Wahl dieses Controllers gefragt, der ja wieder einmal nicht im Mainstream liegt. Als die Entscheidung anstand waren die neuen NXP-Microcontroller mit guten und sehr preiswerten Debuggern ausgestattet, zu dieser Zeit noch nicht Standard. Er ist um einen ARM-Cortex-M0+ Kern herum aufgebaut, für Controller dieser Größe heutzutage die aktuelle Wahl. Dieser Kern hat ausreichend Power um mit den anfallenden Berechnungen "spielend" fertig zu werden, immerhin eine ganze Reihe von double-Rechenoperationen. Er hat die erforderliche I²C-Schnittstelle, 3 UARTs (und für die gibt's durchaus potenzielle Anwendungen) und 16k Flash - davon ist erst die Hälfte verbraucht. Einen Analog-Eingang vermisse ich bei dieser Anwendung nicht. Das TSSOP-16-Gehäuse ist für mich gerade noch lötbar und inzwischen sind die Dinger auch allgemein erhältlich (z.B. bei ⇒HBE - vor 2 Jahren bin ich noch zur NXP-Niederlassung nach München-Perlach gefahren und dort auf einen ausgesprochen verständnisvollen Applikations-Ingenieur gestoßen:-). Warum einen Controller nehmen, der weniger gut geeignet ist? Natürlich kann es dann passieren dass man bei den nachfolgenden Entscheidungen dieser Art wieder erst mal bei NXP vorbei schaut und auch fündig wird, aber dann wird's höchste Zeit für einen angemessenen Platz dieses Herstellers auf den Wunschlisten.
Als Drucksensor kam der damals beste, erhältliche und bezahlbare zum Einsatz, der MS5611. Mangels Löt-Möglichkeiten nahm ich einen auf einem Breakout-Board. Da der Sensor lichtempfindlich ist habe ich das Breakout Board in einen dunklen Schrumpfschlauch gesteckt, im Bild schaut er an der Unterseite ein wenig heraus.

Wie alle anderen Drucksensoren auch (die ich kenne) läuft auch der MS5611 "ein wenig weg" (Drift), am deutlichsten ist dieser Effekt nach dem Einschalten, auch nach sehr kurzen Pausen, zu bemerken. Allgemein führt man das auf thermische Effekte zurück. Ein Seglelflugmodell, das in gut 1m Höhe über Grund an der Winde freigegeben wurde, landet dann in 4m Höhe (oder auch, noch seltsamer, in -2m Höhe) auf dem Boden. Das ist nicht schlimm, aber wenn man was dagegen unternehmen könnte, wär's fein. Ich habe ein paar Zeilen Code eingebaut, die erkennen, wenn das Modell sich über 2 Minuten nicht vertikal bewegt hat; sie setzen dann voraus, dass das Modell am Boden liegt und stellen die Höhe auf 0 - dann stimmt sie wieder halbwegs für den nächsten Start. Ein wenig hift's, und wenn's auch nur ist, dass man was unternommen hat, aber eine "gute" Lösung sieht anders aus.

Das Gerät ist noch nicht fertig: Es fehlt noch eine Technik zum Einstellen der Betriebsparameter (was man bei Multiplex-Sensoren z.B. mit dem orangen Knochen machen kann), der Speicher ist erst zur Hälfte voll, es passen also noch weitere Funktionen hinein (ich denke an ein Energie-Monitoring für kleine Segelflugmodelle) und, last but not least, es ist noch ein Bug drin den ich noch nicht erlegt habe...(Jan. 2015 :-) Aber es ist schon mal was zum Spielen.
Nachtrag 28. April 2015: Jetzt gibt es ein primitives Windows-Konsolprogramm zur Einstellung der Betriebsparameter. Ferner wurde die Ausgabe der hochauflösenden Höhe in 128 Schritten eingebaut um Experimente wie weiter oben angegeben zu ermöglichen.

Womit das alles begann...Rückblick 2010, 2011
Haptische Anzeigen
Haptische Anzeigen

Mit dem Kauf einer 2.4GHz-Anlage bekam ich die Gelegenheit, einmal eigene Ideen zur Erfassung und Anzeige von Flugdaten zu verwirklichen. Ich achtete darauf, dass am RC-Empfänger eigene Sensoren und im RC-Sender eigene Anzeige-Geräte anschließbar sind - als eh schon treuer Multiplex-Kunde nahm ich erleichtert zur Kenntnis, dass das bei dieser Marke möglich ist (das gewohnte Qualitätsniveau war selbstverständlich ebenfalls ausschlaggebend). Sensoren darf man "offiziell" anschließen, das Datenformat und Leitungsprotokoll kann man bei Fa. Multiplex erfragen. "Unten" im Sender ist der Datenstrom nicht offengelegt und daher auch von mir nicht zu erfahren, aber es gibt genug Foren, wo man nachschauen kann (Haftungsausschluss beachten!).

Mein erstes Projekt war ein Inclinometer-Sensor und eine haptische Anzeige für das Steigen und die Lage des Modells relativ zum Scheinlot, eben den Wert des Inclinometers. Ich versprach mir davon eine Verbesserung meiner Flugkünste beim Kreisen. Im Sommer 2011 konnte die erste ausführliche Erprobung stattfinden.

Die Anzeige besteht aus zwei einfachen Servo-gesteuerten Hebeln mit Referenzmarken die mit den kleinen oder Ringfingern während des Steuerns bequem abzutasten sind (siehe Bilder). Sie eignen sich z.B. für die nahezu lautlose Anzeige des Varios. Die Urteile der Kameraden reichen von simpler Ablehnung ("..würde mich nerven...") bis zur begeisterten Zustimmung bei wildfremden Modellflugkameraden am Hang über St. Moritz - alleine dieser eine Nachmittag war schon den ganzen Aufwand wert... Ich habe mich sehr an diese Anzeige gewöhnt und möchte sie nicht mehr missen. Es wird ein Redesign dieser Mimik mit größerer Leistungsfähigkeit und Ausbaufähigkeit geben.

Generell bin ich der Überzeugung, dass die haptische Anzeige einen festen, bedeutenden Platz in der Modellflug-Telemetrie einnehmen wird. Selbst wer nur diese eine, noch recht primitive Anzeige "erlebt" hat kommt ins Grüblen, wie denn ein völlig neues RC-Gefühl sein könnte, bei dem der Modellpilot mit fast allen Sinnen "bei seinem Modell sein kann".

Das Inclinometer, die Anzeige des Winkels des Flugmodelles zum Scheinlot (in einfachen Instrumenten oft als Libelle implementiert) hat zwar funktioniert, aber die Anzeige war nichts wert: Die Aktualisierungsrate der Anzeige ist bei heutigen Telemetrie-Anlagen zu gering. Außerdem zeigte sich, dass das Flugmodell, auch mein recht wenig eigenstabiler MiniMach, in "normalen" Flugzuständen die 90° zum Scheinlot fast immer "gut genug" einhält so dass so ein Sensor nicht gerechtfertigt erscheint; der Fehler ist selten >5°. Schieflagen, z.B. beim Kreisen, kommen auch stets so abrupt, dass sie mit einem Inclinometer nicht hätten vermieden werden können. Also: Friede seiner Asche.

Ich wurde schon gefragt (gescholten) warum ich als Microcontroller nicht einen der gängigen ATMEL-Chips eingesetzt hatte, sondern einen Freescale-HCMwerweißwas-8-Bitter. Ganz einfach: Das Ding war seinen Aufgabe voll und ganz gewachsen und zum Debuggen hatte ich für ganze 10€ einen SpYder bekommen (einen weiteren auf der electronica sogar geschenkt). Vergleichen Sie das einmal mit den 40+€ für einen ATMEL-Dragon. Und mir sind noch die Warnungen vor den Fuse-Fehlern im Gedächtnis, mit denen man so einen Controller unbrauchbar machen konnte. Außerdem mag ich keine Harvard-Architekturen wenn's um C-Programmierung geht (zugegeben: pingelig).