STETTMAIER'S MULTIPLEX- SEITE

Der Multiplex Sensor Bus

Ich erlaube mir jedoch, Fragen zu stellen, Probleme aufzuzeigen und Ergänzungen bzw. Verbesserungsvorschläge anzubringen wenn ich glaube, sie könnten nützlich sein.
Die Funkstrecke wird hier nicht beleuchtet.

Eine einfache Telemetrie-Übertragung für Modelle besteht, sehr vereinfacht dargestellt, aus 3 Schichten, die im Folgenden skizziert sind. Eine Zuordnung der Schichten zum OSI-Modell ist nicht beabsichtigt.
In den unteren Schichten sind Sensor- und Anzeige-Seite fein säuberlich getrennt, in der logischen Schicht jedoch wird das ganze System betrachtet, auf der einen Seite physikalische Werte, auf der anderen Seite der Wunsch, sie darzustellen; hier müssen Werte/Anzeigen, Benennungen, Darstellungsformate zusammenpassen.
Der "natürlichen" Leseweise folgend sind die Datenübertragungen von "low" (physikalische Schicht) nach "high" beschrieben.

Sensor-Seite:
Im gesteuerten Modell werden die Sensoren mit dem M-LINK-Empfänger über eine 3-Adern-Leitung verbunden, dem "eigentlichen" MSB (nur eine Ader für die Signale, daher die Bezeichnung 1-Draht-Bus). Die elektrischen Eigenschaften sind, soweit in der Spezifikation angegeben, unspektakulär.
 

Die Kommunikation auf der Anzeige-Seite wird von Fa. Multiplex nicht offen gelegt, ich tue es auch nicht. Sinnvoll ist vielleicht nur die Anmerkung, dass diese Kommunikation an der DIN-Buchse nicht abgehört werden kann (so sehr man sich das vielleicht auch wünschen möchte).

Sensor-Seite:

Adressierung:
Egal wie die Datenblöcke ausgetauscht werden, stets muss für jeden Datenblock klar sein, wo er herkommt - dafür dient die "Adresse". Wo die Daten hingehen sollen ist beim MSB trivial, muss also nicht angegeben werden. Es gibt hierfür eine Reihe von Verfahren (auch ziemlich "schräge" ), Multiplex hat sich für das einfache, sichere Mit-Übertragen der Adresse in jedem Datenblock entschieden. Diese Adressen sind sowohl auf der Sensor- als auch der Anzeigen-Seite in den Datenblöcken enthalten. Man hat 4 Bits für die Adresse vorgesehen, kann also bis zu 16 verschiedene Sensoren an den MSB anschließen - es ist möglich und üblich, mehrere Sensoren in jeweils ein Gerät einzubauen. Heute erscheint das ausreichend, aber wer weiß, auf was für verrückte Ideen manche Anwender oder Sensor-Bauer kommen, so dass die 4 Bits eventuell knapp werden können.

Adressen müssen eindeutig sein, das liegt auf der Hand. Es gibt im IT-Bereich recht komplexe Verfahren (die, wenn sie mal wieder nicht funktionieren, so richtig Ärger machen...) um einem Gerät, das an einen Bus angeschlossen wird, eine Adresse zuzuteilen. Wenn dies beim Anschließen des Gerätes oder beim Einschalten des Busses oder sogar während des Betriebes passiert nennt man die Zuordnung "dynamisch"; wenn die Adressen auf irgendeine andere Weise ausserhalb des eigentlichen Betriebes passiert, und sich während des Betriebes nicht ändert, dann nennt man die Zuordnung "statisch". Beide Verfahrensarten haben Vor- und Nachteile: Das komfortable "Plug and Play" funktioniert nur mit dynamischer Zuteilung, die statische Zuteilung ist jedoch um Größenordnungen simpler. Beispiel: Früher, als ich noch jung war, das ist schon eine Zeitlang her, gab es für die statische Einstellung von Magnetband-Laufwerk-Adressen (!) kleine "DIP-Schalter" oder auch "Mäuseklaviere", mit denen man einem ausgeschalteten Gerät eine Adresse "verpassen" konnte - das waren noch Zeiten... Multiplex hat sich hier für die statische Zuordnung der Adressen an die Sensorwerte entschieden; aufgrund der geringen Komplexität und dem recht einfachen Aufbau des MSB ist diese Entscheidung durchaus nachvollziehbar. Die statische Adressen-Zuordnung hat jedoch auch Nachteile:

• Der Benutzer muss sie explizit vornehmen wenn er mit den Fabrik-Voreinstellungen nicht zurecht kommt und er kann Fehler dabei machen - jetzt sag' ich's explizit: Es ist nicht zulässig, mehreren Sensorwerten die gleiche Adresse zuzuordnen, denn dann würden sie gleichzeitig auf den Bus geschrieben und die Daten dadurch verstümmelt werden. Und...
• er braucht ein Konfigurations-Gerät dazu, ein Multimate (auf dem neuesten Stand) oder einen Windows-PC mit einem USB→MSB-Adapter... oder aber einen guten Fachhändler, der's für ihn macht.

Anzeigen-Seite:
Datenstrom (zum Mithören): Wie schon erwähnt legt die Firma Multiplex diesen Teil der Kommunikation nicht offen.
Aktualisierungsrate:
Überraschend ist jedoch, dass "unten" die Pausen zwischen den Datenblöcken deutlich größer sind als "oben". Das HFM4 sendet ca. 40 Werte/s zur Anzeige (das ist die Aktualisierungsrate) - vergleichen Sie dies mit der Abfragerate von ca. 160 Werte/s. Ich habe beobachtet, dass selbst wenn "oben" nur 4 Sensorwerte erzeugt werden (2 im M-LINK-Empfänger und 2 vom Spannungs-Sensor) "unten" nicht alle Daten vom HFM4-Modul ausgegeben werden, auch wenn dies bei der Aktualisierungsrate möglich wäre: Es kommen immer noch "Null-Blöcke" ohne Daten aus dem HFM4 heraus.
Solange die Messwerte im Display landen und höchstens das Vario in seiner ganz besonderen Art und Weise piepst wird man die verringerte Aktualisierungsrate kaum bemerken. Wer jedoch eigene Geräte (Sensoren, Anzeigen) entwickeln will muss hier unbedingt beachten, dass keinesfalls alle Daten, die über den MSB gehen, auch nach "unten" gefunkt werden, dass also lange Datenblöcke nicht so einfach sequenziell aufgeteilt übertragen werden können. Wenn man bei eigenen Sensoren/Anzeigen eine hohe Aktualisierungsrate braucht kann man sich evtl. mit einem ganz besonders fiesen Trick behelfen und den (Eigenbau-) Sensor seinen Wert über mehrere Adressen auf den Bus senden lassen und hoffen, dass er dann auch öfter übertragen wird (das macht natürlich nur Sinn wenn der Wert nicht auf dem Display abgelesen werden soll).

Adressierung, Anzeige-Plätze:
Aus der Datenschicht ist die vergebene Adresse eines Sensors bekannt. Es ist zwar nicht die reine, wahre Lehre, aber diese Information wird bei Multiplex dazu verwandt, die Stelle im Display festzulegen, an der der Wert dargestellt wird (Sensor n auf Anzeigeplatz n). Es werden jeweils bis zu 3 Werte gleichzeitig auf bis zu 5 "Seiten" angezeigt und es liegt beim Benutzer, durch geschickte Adressenzuteilung die bestmögliche Aufteilung zu finden. Einen Anzeigeplatz für den Sensor mit Adresse 15 gibt es nicht - damit ist die Anzahl der sinnvoll anschießbaren Sensoren auf 15 beschränkt. Wer Telemetrie mit dem Cockpit-SX-Sender betreibt kann nur 8 Sensor-Adressen benützen. 
Schon einfachste Beispiele zeigen, dass solche Adressen-Verteilungen Modell-spezifisch sind, damit muss man umgehen. Die meisten Sensoren sind mehr oder weniger fest in ein bestimmtes Modell eingebaut und können daher auch modellspezifisch parametriert werden (z.B Adressenzuteilung). Lediglich teure Sensoren, wie der M-LINK-Empfänger selbst oder das Vario, werden öfters umgebaut und sind dann evtl. nicht optimal mit Adressen versehen.
Das mag jetzt weit hergeholt klingen, daher will ich ein Beispiel angeben: Meine beiden kleineren Segler haben eine einfache Stromversorgung und folgende Anordnung der Adressen liegt nahe: 0: Empfängerspannung, 1: LQI, 2: Höhe (das sind die Werte, die ich gelegentlich ablese, die anderen Werte lasse ich mir auf andere Weise anzeigen). Der Flamingo hat jedoch eine doppelte Stromversorgung und die Empfängerspannung des M-LINK-Empfängers wird unwichtig und durch 2 Werte eines Spannungssensors ersetzt. Also: U₁ auf 0, U₂ auf 1 und auf 2 kommt die Höhe oder der LQI. Man muss also den Empfäger umparametrieren. Weiterhin sollte man beachten, dass man während des Fluges sicherlich nicht ohne weiteres Display-Seiten umschalten kann denn da schaut man zu lange vom Modell weg, dass also die 3 als wichtig erachteten Werte gemeinsam angezeigt werden müssen.
Es kursiert schon die erste Liste im Internet, in der die Messwerte fein säuberlich nach Anzeigeplätzen sortiert aufgezählt/empfohlen werden - für alle Modelle. Hallo! Geht's noch? Das kann's doch nicht sein! Ich such' doch nicht auf 5 Display-Seiten nach den wichtigsten Werten weil ich die Flexibilität, die M-LINK bei der Anzeige bietet, vergeudet habe! Nochmal: Die 3 mir als wichtigste erscheinenden Werte kommen auf Seite 1 (Adressen/Anzeigeplätze 0..2). Nur die lese ich ab. Was anders dargestellt wird (derzeit nur das Vario) brauch' ich nicht ablesen, das kommt woanders hin. Mehr noch: Werte, die mich erst interessieren, wenn's einen Alarm gibt, brauch' ich doch nicht auf Seite 1, oder? Die ROYALpro schaltet die Anzeige um wenn ein Alarm kommt. Diesen Komfort muss man ausnutzen und solche Werte auf Seite 2ff "legen" (Leider gibt es für den LQI keinen Alarm, wer sich also dafür interessiert muss ihn auf Seite 1 belassen).

Semantik der Daten:
Zwischen Sensor und Anzeige muss vereinbart werden welche Bedeutung ein gemessener und übertragener Wert hat; auch hier gibt es statische und dynamische Vorgehensweisen. Die allereinfachste Methode wäre, die Semantik durch Verabredung festzulegen: Im Datenblatt des Sensors steht "Das Ding misst die Steigrate in m/s" und dies wird für die Anzeige dann "irgendwie" manuell eingetragen - oder es wird garnichts gemacht und der Benutzer muss sich das einfach merken.
Oder es wird mit dem Wert ein Code übertragen, der die Semantik des gemessenen Wertes spezifiziert.
Multiplex hat sich zum Teil für die einfachste statische und in einem Punkt für die allereinfachste Methode entschieden: Ein Code definiert physikalische Einheit und das Format des gemessenen Wertes, das was gemessen wird muss sich der Benutzer merken. Dies ist leider nicht besonders felxibel: Es gibt nur die von Multiplex definierten Datenarten und -Formate (siehe "Klassen" im Anschluss), es bleibt wenig Raum für eigene Überlegungen, die nicht mehr oder weniger zufällig in das Multiplex-Schema passen. Ein paar mehr Details dazu:

Klassen (=Formate & Benennungen):
Das für den (fixen) Semantik-Code vorgesehene Feld ist 4 Bits groß und wird immer zusammen mit den Daten übertragen. Die 4 Bits erlauben bis zu 16 Werte-"Klassen", wie man bei Multiplex sagt (die 0 ist anders vergeben, also sind's nur noch 15). Eine Klassendefinition legt die 2 wichtigsten Komponenten einer Messwert-Semantik fest: Physikalische Benennung und Auflösung/Zahlenformat. 13 der Klassen sind schon definiert, 2 können noch festgelegt werden. Der große Vorteil dieses Verfahrens liegt wirklich (und nur) in der Einfachheit: Man muss im Sender nichts tun und kriegt alles angezeigt.
Die Klassen und damit auch die Auswahl an Werten und die zugehörigen Anzeigeformate sind zwischen Sensor und Anzeige fest verabredet. Das klingt trivial, aber die Betonung liegt auf dem Wörtchen "fest": Man kann sie nicht ändern. Wenn eine der beiden letzten freien Klassen definiert wird, wohl aufgrund der Einführung eines neuen Sensors, braucht's einen Update des Senders; dynamisch änderbare Klassen würden ein gehöriges Plus an Felxibilität bringen. Über dynamisch änderbare Klassen denkt man allerspätestens nach, wenn die beiden letzten Klassen-Codes verbraucht sind und der Wunsch nach mehr aufkommt. Und das kann eher passieren als einem lieb ist.

Auflösungen:
Leider hat man insbesondere bei der Festlegung der meisten Auflösungen offensichtlich nur an eine bestimmte Anwendung gedacht und die Universalität zu sehr vernachlässigt: Spannungen sollen oft mit wesentlich feinerer Auflösung als 0,1V gemessen werden, wenn's nicht gerade der Antriebsakku ist. Ebenso wünscht man sich auch beim Strom oft eine feinere Auflösung als 0,1A, z.B. in kleineren Segelflugmodellen. Mit Auflösungen im 10mV- und 10mA-Bereich wäre mehr zu erreichen, zumal die dann noch möglichen Wertebereiche von ±160 V bzw. A nach heutigem Ermessen auf jeden Fall ausreichen.
In diesem Zusammenhang ist interessant, dass für die Klasse 11, den "Stromverbrauch", mit 1 mAh eine recht gute Auflösung definiert wurde. Dies erlaubt auch einen optimalen Wertebereich von gut ± 16 Ah. Aus meiner Sicht gibt es exzellente und wichtige Anwendungsmöglichkeiten dafür (siehe ►weiter unten).

Benennungen:
Derzeit ist für jede Klasse die Benennung der Messgröße unveränderlich festgelegt; Beispiel Geschwindigkeit in km/h. So etwas sollte jedoch alleine in der Anzeige entschieden werden und vom Benutzer konfigurierbar sein. Dann könnte man, wenn's geeignet erscheint, Fluggeschwindigkeiten auch in m/s anzeigen - oder in einem anderen Teil der Welt, wo man zum Messen von Längen noch die Füße (Schuhgröße 47) verwendet, eben auch in mph oder ft/s anzeigen lassen, egal wie's der Sensor erzeugt ("Lokalisierung").

Wertebereiche:
In der Spezifikation ist für jede Werteklasse auch festgelegt, in welchen Bereichen sich die zu übertragenden Werte bewegen dürfen. Die Wertebereiche sind nicht auf das mögliche sondern auf ganz bestimmte Sensoren festgelegt (Beispiel: Klasse 7, Richtung: 0..360°). Dies hat natürlich nichts mit einer Datenübertragung zu tun - es ist lediglich eine technische Eigenschaft der verwendeten Sensoren. Nun ist es glücklicherweise so dass weder die Datenübertragung noch die Anzeige im Sender diese Einschränkungen erzwingen - die Angaben in der MSB-Spezifikation sind dort schlichtweg überflüssig. Ich kann also z.B. die Klasse 7 durchaus auch zur Übertragung eines Inclinometer-Wertes oder Schiebewinkels im Bereich von ± 20° verwenden obwohl laut Spezifikation nur 0-360° erlaubt sind.

Namen für Werte ("Symbolische" Adressen):
Wie in den bisherigen Texten zu erkennen ist gibt es keine Möglichkeit festzulegen, was für eine physikalische Größze gemessen und übertragen wird, nur welcher Art sie ist. Nochmals als Beispiel: Eine Geschwindigkeit kann eine IAS, TAS, GroundSpeed oder etwas anderes sein, an das man heute noch garnicht denkt. Selbst wenn man meint, eine Angabe "km/h" sei selbsterklärend: Sehr viele Größen im Flugmodell kann man mehrfach messen und die (Modell-spezifische) Zuordnung ist nicht trivial. An der Definition von Klassen für ganz bestimmte individuelle Messgrößen lese ich ab, dass die Unklarheit bei Multiplex vielleicht nicht so klar gesehen wird: Klasse 10 ist alleine für den LQI vorgesehen und Klasse 3 alleine für das Vario (inklusive Bug). Es gibt aber potentiell viele Stellen, an denen Spannungen, Ströme, UPMs, Temperaturen, Tank-Füllstände oder Ladungsmengen gemessen werden. Natürlich will man diese "unten" abzulesenden Daten nicht unbedingt anhand ihres Anzeige-Platzes identifizieren, da kann es zu Verwechslungen kommen.
Nützlich wäre es, jeden Anzeigeplatz mit einem Namen zu versehen, der die Bedeutung des angezeigten Wertes deutlich macht (z.B. "B1" und "B2" für die 2 Empfängerbatterien). Dies ist jedoch beim aktuellen ROYALpro-Sender nicht vorgesehen. Wenn man bedenkt, dass alleine ein Spannungssensor bis zu 4 Spannungen ausgeben kann und der M-LINK-Empfänger zusätzlich eine fünfte, wird man verstehen, dass das nicht immer optimal ist - es muss alleine aufgrund des Anzeigeplatzes zwischen verschiedenen Größen mit gleicher Benennung unterschieden werden. In extremen Fällen wird es dann dazu kommen, dass Zettel an das Display gepappt werden...(vielleicht etwas spitz formuliert). Die Tatsache, dass Listen mit "Standard-" Adresstabellen (im Internet und auch in der FMT) mit "Klartext" angegeben werden sollte bei Multiplex zu denken geben (So wie ich die Leute dort einschätze wird man denen das nicht sagen müssen - es gibt bestimmt andere Gründe für diesen Mangel).
Meistens ist in der Anzeige rechts neben dem (erfreulich groß dargestellten) Wert und Benennung ausreichend viel Platz für eine kurze Identifikation des Wertes; beim LQI hat man das ja schon gemacht. Bei den anderen Werten kann das der Hersteller natürlich nicht vorherbestimmen, da muss der Benutzer mit der Tastatur nachhelfen (bzw. →nachhelfen können).

Alarme:
Für (fast?) alle Sensorwerte kann man in den Sensoren auch Alarmschwellen angeben, bei deren Über- oder Unterschreitung der Sensor ein Alarmbit setzt, das dann "unten" für Radau und invertierte Anzeige sorgt. Sehr gut finde ich, dass bei Alarm das Display automatisch auf die Seite umgestellt wird, in der der alarmierende Wert steht - und nach einer gewissen Zeit auch wieder zurück schaltet.
Man könnte sich natürlich auch wünschen, diese Alarmschwellen "unten" im Sender - modellspezifisch - einzustellen und auch abzuschalten, dann könnte man sie leichter ändern, sogar während des Fluges. Auf jedem Anzeigeplatz kann man genau einen Alarm darstellen, dies erfolgt durch inverse Darstellung und einen Ton. Ein einzelner Sensor kann nicht verschiedene Alarme erzeugen - das mag theoretisch klingen, aber es wird kommen.

Wechselnde Anzeigen:
Das Konzept verbietet nicht dass ein vielleicht etwas komplexerer Sensor zeitlich gestaffelt verschiedene Daten, sogar aus verschiedenen Klassen, unter einer einzigen Adresse überträgt. Dies wird derzeit jedoch nicht genutzt. Es könnte sinnvoll sein, "normale" Messungen gemeinsam mit Ausnahme-Messungen und Alarmen zu kombinieren und dabei nur einen Anzeigeplatz zu "verbrauchen". Es kommt mir dabei nicht so sehr auf die eingesparte Adresse an, vielmehr wird es möglich auch komplexere Vorgänge zur Anzeige zu bringen ohne dass der Modellpilot zwischen Anzeigeseiten blättern muss.

Kurzfristige (kleine) Verbesserungsvorschläge

Der MSB ist sehr einfach gehalten, daraus ergeben sich manche Einschränkungen, die dem ambitionierten Bastler engere Grenzen anlegen als ihm lieb ist. Damit wird auch die Versorgung des Anwenders mit speziellen, weiter entwickelten (evtl. auch nur für wenige Leute wirklich interessanten) Sensoren und Anzeigen geringer ausfallen als gewünscht.
Die "Bodenstation" der Telemetrie ist auf den ROYALpro aufgesetzt und erweist sich in der aktuellen Form als nicht ausreichend. Es wird bestimmt 2 Wege geben, hier Fortschritte zu erzielen:

• Weitere Updates für die ROYALpro-Sender: Multiplex hat ja in vorbildlicher Weise stets an die Käufer der früheren Anlagen gedacht und mit Updates wesentliches geleistet um diese Anlagen up to date zu halten. Die augenblickliche Top-Anlage ROYALpro wurde ja explizit als Telemtrie-Alage erneut vermarktet (und das war ja auch für mich ein Kaufgrund). Die Kunden erwarten selbstverständlich, dass das im Rahmen des möglichen weitergeführt wird, d.h. dass die Anlage ohne oder mit minimalen Hardware-Änderungen die neuesten Tricks so weit wie möglich über Software-Updates "mitkriegt". Ich beschränke mich weitestgehend auf diese Variante der Produktpflege.
• ...sowie natürlich die Entwicklung eines neuen Senders.

• Die Möglichkeiten der Anzeige von Telemetrie-Werten "unten" für den Piloten sollten dringend erweitert werden. Die Vielfalt der Anzeigen kann sehr groß werden und es ist möglich, dass es Sonderformen in geringen Stückzahlen geben wird, z.B. für Behinderte. Dies spricht dafür, dass auch "unten" am Sendergehäuse eine öffentlich gemachte Schnittstelle geschaffen wird. Die DIN-Buchse an der Unterseite des Sendergehäuses bietet dies derzeit nicht, könnte aber prädestiniert für so eine Funktionalität sein (evtl. wäre nur ein Software-Update erforderlich). Ein sehr einfaches Beispiel für so eine "externe" Anzeige ist die akustische Vario-Ausgabe (die später ganz sicher mit einer Sprachausgabe für weitere Werte ergänzt wird).
  Schade, dass Fa. Multiplex dies anders sieht.
• Vergabe von Namen für Messwerte und freie Positionierung in der Anzeige: Im Sender sollte es möglich werden, für jeden Sensorwert einen Namen zu vergeben und den Anzeigeplatz zu wählen (Modell-spezifisch). Eine simple technische Lösung wäre z.B. eine (Modell-spezifische) Tabelle Adresse→[Anzeigeplatz,Text]. Etwas weitergesponnen wird man möglicherweise den Wunsch haben, auch andere Daten (Stoppuhr?) mit Telemetrie-Daten gemeinsam auf einer Display-Seite anzuzeigen. Beispiel (wieder mein MiniMach): 0 U_Batt, 1 Stoppuhr, 2 Höhe; dann brauch ich keine Display-Seiten zu blättern.
  Ein echtes Problem bei der Realisierung einer Lösung ist der Bedarf an weiterem Speicherplatz an einer Stelle, an der keiner mehr übrig ist...
• Eine Priorisierung als "zeitkritisch" erachteter Daten: Es muss möglich werden, bestimmte Daten (Klassen oder individuelle Sensoren) auf jeden Fall "ausreichend oft" durch den Flaschenhals der Übertragung vom HFM4 zum Sender zu bekommen (alternativ kann man natürlich diese Schnittstelle schneller machen). Damit gewährleistet man auch bei vielen angeschlossenen Sensoren flüssige Anzeigen z.B. für das Vario. Ebenso könnte es recht nützlich sein, einen Wert, bei dem der Alarm gerade angegangen ist, für kurze Zeit mit höherer Priorität zu senden.
  Update: ingo_s war wieder mal am schnellsten was Neuigkleiten angelangt: Im ►RC-Network gibt's einen ganz kleinen Blick in die Zukunft: Man wird eine Sensor-Adresse höher als die anderen priorisieren können. Das dürfte wohl vor allem für das Vario eingesetzt werden. Das ist zwar nicht mein ganzer Wunsch, aber ... mal sehen.
• Größere Datenblöcke: Es wird Sensoren geben, die mehr als 2 Bytes Daten generieren. Gibt's dafür schon Überlegungen?
• Man möchte Alarmschwellen auch "unten" einstellen und Alarme auch "unten" abstellen können.
• Dinge wie graphische Anzeigen sind hübsch, aber man muss sich hier schon kritisch nach der wirklichen Verbesserung im Gebrauchswert fragen - andere werden das sicherlich anders sehen wie ich, da bin ich ein wenig eigen. Selbstverständlich sind Graphiken meistens gut, aber nicht in einem relativ kleinen, monochromen und mit geringen Kontrasen gesegneten Display. Eine besondere Form der graphischen Darstellung wäre z.B. das Lauflicht, als Vario-Anzeige einsetzbar.
• Kleinigkeit: Es wird Geräte/Sensoren geben, die zur Erfüllung ihrer Aufgabe auch die Werte von anderen Sensoren am MSB lesen - da spricht ja nichts dagegen (siehe auch das ►Logging weiter unten). Nur müssen dann auch alle Werte tatsächlich auf dem Bus verfügbar sein, auch die, die der M-LINK-Empfänger selbst akquiriert und derzeit nicht auf den MSB ausgibt: U_Batt und auch der LQI.

Neue Sensoren: Bei Multiplex hat man ganz offensichtlich schon eine ziemlich umfangreiche Palette von Sensoren zumindest "in der Pipeline", es wird sicherlich nicht so einfach gelingen, hier noch wesentlich neues für den "Mainstream" zu bringen. Sehr vorteilhaft wird sich auswirken, dass auch ACT MSB-Sensoren auf den Markt bringen will. Ich mag es sehr, wenn Leute vernünftig sind... Natürlich darf man neugierig sein, wie sich diese Sensoren hier einfügen werden. Hier nun meine Vorstellungen:

• Energie-Management: Wenig spektakulär, aber sehr nützlich. Bisher gibt es nur zaghafte Versuche, den Ladezustand und das Leben der Stromversorgung im Flugmodell zu verfolgen. Es gibt genug Gründe um auch für kleine Segelflugmodelle die Energie sorgfältig zu überwachen und Probleme nach "unten" zu melden. Vorteile: Ein Plus an Sicherheit (klar, nicht neu) und verlängerte Betriebszeiten, denn die Akkus können ohne Risiko leerer geflogen werden als bisher. Ich kann mir vorstellen, dass es recht verschiedene Geräte/Sensoren für diese Anwendung in verschiedenen Größen geben kann. Auch Sonderfälle, z.B. für solar-betriebene Modelle, sind denkbar - ein weites Betätigungsfeld für Kleinsthersteller und Bastler. Damit das nicht allzu nebulös klingt hier beispielhaft ein paar konkrete Anforderungen an so einen Sensor für einen kleinen Segler:
  1. Lade- und Entladezustand des Akkus erfassen, über mehrere Einsätze hinweg speichern ("den Akku kennenlernen"), den Entladezustand nach "unten" melden. Der Zustand des Akkus kann evtl. über die Spannung nur ungenau erfasst werden, daher ist ein Integral über den Strom von Nutzen.
  2. Erfassung von Problemen bei mehrzelligen Akkus, wenn eine Zelle schlapp macht.
  3. Erfassung von Spannungseinbrüchen (auch die kürzesten).
  4. Messung des Stromes und bei Überschreitungen von definierbaren Schwellen Alarm melden.
  5. Man sollte in so ein Gerät auch den FET-Einschalter und ein Peak-Filter integrieren.
  So ein Gerät wird mehrere Werte nach "unten" senden: Spannung (Klasse 1), Strom (Klasse 2, aber mit feinerer Auflösung), Spannungseinbrüche und Stromspitzen in den letzten n Sekunden, entnommene Energie (Klasse 11, mAh) und den (Ent-) Ladezustand (Klasse 9, %). Zu jedem Wert ist auch ein angemessener Alarm denkbar. Das sieht nach recht viel aus, aber das MSB-Konzept verbietet ja nicht, dass ein Gerät über die Zeit mehrere verschiedene Werte (auch verschiedener Klassen) über die gleiche Adresse auf den gleichen Anzeigeplatz ausgibt.
• Etwas, auf das die E-Flieger hoffentlich nicht allzu lange warten müssen: Wer weiß am genauesten Bescheid über die Spannung am Antriebs-Akku, den Strom im Antriebsstrang und die Drehzahl? ...und kann daraus abzuleitende Werte (Leistung, Last) am besten ausrechnen? Richtig, der Drehzahlsteller. Ich bin ganz sicher, dass es Drehzahlsteller geben wird, die solche Werte auf den MSB ausgeben. Multiplex selbst ist prädestiniert, diesen Baustein mit absolutem <WOW!>-Effekt herauszubringen und die Vorteile der integrierten Telemetrie aus einer Hand überzeugend hervorzuheben. Natürlich hat schon jemand an sowas gedacht und mit einem Logging-Adapter für den Jive-Regler eine erste Referenz geschaffen.
  Update: Selbstverständlich mache nicht nur ich mir solche naheliegenden Gedanken; praktisch jeder einschlägige Hersteller hat so einen Drehzalhsteller bereits im Labor und das Warten sollte nicht mehr allzu lange dauern; dies war bei Gesprächen auf der Friedrichshafener Messe 2010 überdeutlich zu hören.
• Stromsensor: Zumindest den Strom möchte man in kleineren Modellen in wesentlich moderateren Stärken aber dafür mit höherer Genauigkeit und Auflösung (0.01 A) messen.
• Fluglage-Sensoren zur unmittelbaren Unterstützung des Modellpiloten beim Fliegen: Ich tüftle ja gerade an einem Inclinometer herum, vielleicht kommt auch mal ein Schiebewinkel-Sensor dazu. Solche Werte sollten aber mindestens 8 mal pro Sekunde frisch angezeigt werden, wie auch das Vario. Siehe auch "Priorisierung" ein paar Zeilen weiter oben.
• Speed-Sensor... wieso? Den gibt's doch mit der GPS-Maus? Na, so wie ich das bisher sehe ist das eher ein Ding zum Angeben - ein großes Display vor dem Zuschauerareal zeigt 220km/h an... toll. Aber was brauchen wir wirklich? Ich will, wenn mein Modell kaum noch sichtbar in der Thermik rumeiert ("eiern" stimmt durchaus, und manchmal komm' auch ich so weit rauf... ) ausreichend genau wissen, ob ich knapp am Stall bin oder v_{Vz_min} oder v_{e_max} längst hinter mich gelassen habe; dann fall' ich nicht so oft aus der Thermik raus und so weiter. Hier ist eine IAS-Angabe (nicht Ground-Speed) im Bereich 8..20 m/s mit ±2% Genauigkeit erforderlich - natürlich mit einer entsprechenden Anzeige, eine Zahl im Display hilft da nicht weiter. Ich weiß, das ist kaum (oder garnicht) erfüllbar. Ein GPS-Sensor wird diese Anforderung ganz sicher nicht erfüllen können.
• g-Messung: Das Lastvielfache wird immer wieder gerne bestaunt. Das ist mindestens so wertvoll wie der "Kilometerzähler" der GPS-Maus.
• Das ist zwar kein Sensor, aber es wird bestimmt jemand kommen, der's macht: Logging, die Black Box. Das macht man "oben", nicht im Sender, denn wenn die Verbindung futsch ist soll ja gerade das weitere Geschehen geloggt werden. So ein Gerät hat ACT jetzt angekündigt. Ich weiß, das Unilog gibt's inzwischen auch für den MSB, aber das meine ich nicht - alle Daten, die über den MSB kommen, sollen geloggt werden, nicht nur die selbst erzeugten.

Spannungsversorgung mit dem PC-USB-Adapter

kMSB: Mit dem PC am MSB lauschen und Sensoren simulieren

Das Programm spricht den USB-Adapter über die "virtuelle COM-Port-Schnittstelle" an, die muss man also rauskriegen. Das geht unter WinXP mit dem Geräte-Manager: Start / Einstellungen / Systemsteuerung / System wählen, dann den Hardware-Reiter aufmachen und auf Geräte-Manager klicken. Wenn Sie als ordentlicher Mensch mit Nicht-Admin-Rechten unterwegs sind wird Ihnen das der Geräte-Manager jetzt auch sagen, das macht aber nichts, denn Sie wollen ja nur was anschauen. Klicken Sie auf das '+' bei "Anschlüsse (COM und LPT)", dann finden Sie den Anschluss aufgrund des Textes "MPX PC Interface..." - wenn nicht, dann schließen Sie das Ding halt an, wie soll er's denn sonst finden... Wie's bei Windows7 und Vista geht weiß ich nicht. Bei mir heisst der Anschluss "COM2" und das werde ich in den folgenden Beispielen so verwenden.

Das Programm wird mit folgendem Kommando aufgerufen (es macht Sinn, das Kommando in eine Batchdatei zu schreiben; es macht jedoch keinen Sinn, das Kommando in eine Verknüpfung zu schreiben, denn da kann man keine Log-Datei anschliessen):
kMSB -comn [-verbose] [-raw] ( Sensorkommando )_0..15 [>Logdatei ]
-comn ist der COM-Port-Anschluss, über den der USP-Adapter angesteuert wird; anstelle des n müssen Sie natürlich die richtige Zahl des COM-Ports angeben
Wenn Sie "-verbose" angeben gibt das Programm Zwischenmeldungen aus, die ein irgendwie besseres Karma ausstrahlen als wenn es absolut stumm bleibt.
Wenn Sie "-raw" angeben kriegen Sie die Daten nicht formatiert sondern roh, in binärer Darstellung.
Sensorkommandos sehen so aus: -sensoradr/format=nummer[!] ohne jeden Zwischenraum.
adr ist die Adresse des zu simulierenden Sensors, eine ganze Zahl zwischen 0 und 15.
format ist die Klasse (das Format) des vom simulierten Sensor ausgegebenen Wertes, eine Zahl zwischen 1 und 15.
nummer ist der Wert zwischen -16384 und +16383 und '!', wenn angegeben, setzt das Alarmbit.
Jede Änderung eines Sensorwertes wird im Log angezeigt. Wenn eine Logdatei (mit vorangestelltem Umleitungszeichen '>') angegeben ist geht das Log in diese Datei, sonst ins Konsolefenster.

Da Windows kein Echtzeit-Betriebssystem ist dürfen keine hohen Ansprüche an die zeitliche Genauigkeit der ausgegebenen Signale gestellt weren, aber bei einem halbwegs aktuellen PC, am besten einem Doppelkern-Prozessor, reicht's aus.
Das Program kann mit Ctrl-C angehalten und beendet werden, nach frühestens einer Stunde hält es von selbst an.
 

kMSB V1.0
 2   -18.0 °
 3     -.- V
 4     -.- V
 6     -.- V
 7     -.- V
 3     5.4 V     !
 4     5.4 V     !
 6     5.4 V
 7     5.4 V
Letzter Stand der Sensordaten:
 0
 1
 2   -18.0 °
 3     5.4 V     !
 4     5.4 V     !
 5
 6     5.4 V
 7     5.4 V
 8
 9
10
11
12
13
14
15
kMSB beendet.

kMSB V1.0
2 2798fe >
3 310080
4 410080
6 610080
7 710080
3 316d00
4 416d00
6 616c00
7 716c00
Letzter Stand der Sensordaten:
0 000000
1 000000
2 2798fe >
3 316d00
4 416d00
5 000000
6 616c00
7 716c00
8 000000
9 000000
a 000000
b 000000
c 000000
d 000000
e 000000
f 000000
kMSB beendet.

Installation: Zuerst den Multiplex-PC-Adapter korrekt installieren, dann einfach das Programm (kMSB.exe) auspacken und irgendwohin speichern und dort aufrufen.
...und hier ist es: ►kMSB.exe.zip    Viel Spaß und Erfolg damit!
Ja, ich habe eine Version gemacht, die auch als Master die Adressen durchzählen kann, aber das Timing unter Windows ist so mies, dass ich diese Version nicht veröffentliche.
Das Kleingedruckte: Ich gebe keine Garantie für irgendwas und übernehme keinerlei Haftung aus irgendwelchen Schäden, die Sie mit dem Programm oder den zugehörigen Anweisungen und Tips erleiden oder verursachen. Download, Speicherung, Nutzung und Weitergabe kostenfrei erlaubt - sonst nichts.