Hallo zusammen,
wie viele Jungen war ich schon in frühester Kindheit fasziniert von allem was fliegen kann. Zunächst habe ich dann die damals sehr beliebten Was-Ist-Was-Bücher (die es zu meinem Erstaunen heute immer noch gibt) verschlungen und mir zu Ostern, Weihnachten und zum Geburtstag weitere Bücher gewünscht die meist die Themen Technik, Weltraum oder Luft- und Raumfahrt zum Thema hatten.
Die ersten wirklichen Erfahrungen mit Fluggeräten konnte ich dann mit Drachen sammeln die mein Vater für meinen Bruder und mich gebastelt hatte - oder später auch mit gekauften Plastikdrachen. Das hat zwar schon Spaß gemacht (besonders wenn wir mit meinem Opa drachensteigen waren) - aber es fehlte dann doch die Steuerbarkeit (Lenkdrachen gab es damals zumindest in der öffentlichen Wahrnehmung noch nicht).
Also schlief das natürlich mit der Zeit etwas ein und die weitere Flugerfahrung beschränkte sich auf Papierflieger. Irgendwann habe ich dann gemerkt, dass es bei uns in Mülheim an der Ruhr auf dem Auberg zwei Modellflugplätze gab. Einen für Segler und einen für Motormodelle. Bei jeder Gelegenheit bin ich dann dorthin gefahren und habe den Modellfliegern zugeschaut.
Irgendwann - mit 14 Jahren oder so - habe ich dann auch selbst mit dem Modellflug angefangen. Zusammen mit einem Schulfreund haben wir zunächst Freiflugmodelle gebaut und geflogen. Typische Modelle waren "der kleine Uhu" und die Günther Gummimotormodelle. Auch diese Modelle kann man heute noch kaufen. Die ersten Erfahrungen waren dabei ziemlich durchwachsen. Der kleine Uhu flog natürlich wohin er wollte - und auf dem Auberg gab es reichlich Bäume. Die Gummimotormodelle hatten eine sehr kurze Flugzeit. Also musste irgendwann etwas besseres her.
Der übliche Einstieg - nach ausgiebigen Beratungen durch die Modellflieger auf dem Auberg - war damals ein Amigo von Graupner. Ein einfacher Segler. Gesteuert über Höhen- und Seitenruder. Komplett als Holzbausatz geliefert mit vielen, vielen Einzelteilen und einer Papierbespannung. Den habe ich mir dann vom Taschengeld zusammengespart. Zusammen mit einer einfachen Funkfernsteuerung und den passenden Servos. Und das Teil flog. Aus heutiger Sicht nicht wirklich gut (weil ich mit dem Aufbau wohl auch ziemlich geschlampt hatte) - aber immerhin. An der Hochstartwinde oder im Gummihochstart auf ca. 100 m gezogen konnte ich damit einige Platzrunden drehen. Auch etwas Thermik erwischte ich gelegentlich und dann ergaben sich auch schon mal Flugzeiten von mehreren Minuten...
Einmal von der Modellflugsucht befallen muss es natürlich immer mehr sein. Der nächste Schritt war dann ein "Fuzzy". Dieses Modell wurde von einem Vereinskollegen (natürlich war ich dem Verein mittlerweile beigetreten) in Heimfertigung gebaut. 350 Zentimeter Spannweite mit doppelter V-Form (Knickflügen), GFK-Rumpf und Pendel-Höhenruder. Wow. Riesig. Und die Flugeigenschaften waren auch super. Mit dem Teil konnte man auch schon mal 1-2 Stunden in der Luft bleiben, wenn die Bedingungen gut waren. Absolut einfach zu fliegen war der Vogel auch. Höhen- und Seitenruder. Mehr brauchte es nicht. Nur eins konnte die Kiste nicht: Schnell fliegen. Egal. Segelmodellflug ist halt Entspannung. Nur bei den F3B-Wettbewerben des Vereins hat es dann schon geschmerzt, dass ich kein passendes Modell hatte um mitfliegen zu können. Aber passende Modelle (sehr beliebt waren die Modelle von Carrera wie die Sagitta) waren für mein Schülerbudget einfach unerschwinglich.
In dieser Zeit kamen dann auch erste wirklich fliegbare Modelle mit Elektroantrieb auf den Markt. Meist mit einem Mabuchi 550 Motor und 6-8 Zellen NiCd-Akkus. Leider war sowas komplett mit einem passenden Modell auch wieder sehr teuer. Also versuchte ich meinen Fuzzi zum Elektroflieger zu machen. Mit ziemlich durchwachsenem Erfolg. Damals galten Steigleistungen von 1 m/s schon als gut. Mit dem Fuzzi habe ich deutlich weniger geschafft. Aber "im Prinzip" hat es funktioniert.
Daneben habe ich auch Versuche in Richtung Motorflug gemacht. Mit 2-Takt Methanolmotoren. Diese sind aber allesamt an meinen (fehlenden) Flugkünsten gescheitert. Die Modelle haben den Erstflug in der Regel nicht überlebt.
Damals schon habe ich aber auch eine große Affinität zu Modellhubschraubern gehabt. Allerdings (siehe oben): Die Sache mit dem Budget. Taschengeldfreundlich waren die Preise für Modellhubschrauber nun wirklich nicht. Ein Schulkamerad hatte da offenbar etwas mehr Geld zur Verfügung. Er hat sich einen Elektroheli gekauft. Auf Grund der damaligen Technik konnte man das Ding aber nur "an der Leine" fliegen. Es gab ein Stromkabel zwischen Heli und einer KFZ-Batterie am Boden. So richtig praxistauglich war das alles nicht.
Ich selbst habe dann irgendwann in Dortmund auf der Modellbaumesse einen Verbrennerheli von Conrad günstig kaufen können. Mit dem habe ich dann auch viel gebastelt. Geflogen ist er nie. Nur ein paar Hüpfer von wenigen Zentimetern habe ich geschafft. Kreisel hat man damals noch nicht verwendet. Die Einstellerei eines Helis war (und ist heute noch) kompliziert. Es gab kein Internet wo man sich Tipps holen konnte. Und die Modellflieger im Umkreis hatten mit Helis nichts am Hut. Vibriert hat der kleine Heli auch sehr stark. Irgendwann ist das dann alles eingeschlafen. Mit Mitte 20 habe ich dann mit dem Modellflug auch aufgehört, nachdem ich zwischenzeitlich noch einige wirklich fliegende Modelle hatte (u.a. den Twinstar von Multiplex).
Mit ungefähr 40 Jahren habe ich dann erneut mit dem Modellbau begonnen. Diesmal mit mehr Erfolg - nicht zuletzt durch das Internet in dem man zu allen Bereichen jede Menge Tipps und Tricks finden kann. Mehr dazu im nächsten Blogeintrag.
Samstag, 25. Februar 2012
Montag, 20. Februar 2012
Arduino - Erste Schritte
Hallo!
Wenn man mit dem Arduino entwickeln möchte braucht man natürlich erstmal ein wenig Hard- und Software. Für Experimente mit dem Multiplex M-Link® System ist es praktisch, wenn man eine Hardware benutzt die mit 3,3 Volt arbeite kann, da die Pegel auf dem Multiplex Sensor Bus ebenfalls 3,3 Volt betragen. Leider arbeiten die meisten dieser Arduinos bei 3,3 Volt nur mit 8 MHz Taktfrequenz für den Prozessor. Mehr Rechenleistung kann aber nie schaden. Daher habe ich mich für einen Iteaduino entschieden. Das ist ein Arduino Board welches man zwischen 3,3 Volt und 5 Volt umschalten kann - und es läuft in beiden Fällen mit 16 MHz.
Für die ersten Experimente habe ich mir zusätzlich einige preiswerte Komponenten gekauft:
So sieht meine erste kleine Hardwaresammlung dann aus (alles bereits an den Arduino angeschlossen):
Für die Zusatzhardware benötigt man teilweise noch passende Bibliotheken damit der Arduino die Hardware auch ansteuern und nutzen kann. Für das Display findet sich zum Beispiel hier eine gute Übersicht über die Funktionsweise sowie ein Download Link für die passende Library. Zum Umgang mit den SD Kartenleser finden sich hier alle nötigen Informationen.
Mit den von mir ausgewählten Komponenten kann ich im Prinzip alles machen, was ich mir so vorstelle. Es gibt sicherlich Spielraum nach oben. Beispielsweise sind auch deutlich leistungsfähigere LC-Display verfügbar - sogar mit Touchscreen. Es gibt auch fertige Tastenfelder als Alternative zum Joystick. Die Soundausgabe ist mit dem Piezosummer natürlich auch etwas eingeschränkt. Komplexe Tonfolgen oder gar Sprachausgabe sind damit wohl nicht so einfach möglich. Aber auch hierfür gibt es Möglichkeiten - bis hin zum kompletten MP3 Player den man an einen Arduino ankoppeln und kontrollieren kann. Sogar fertige Module zur Sprachausgabe sind verfügbar (z.B. Speakjet).
Einfach mal google anwerfen und über die unglaubliche Vielfalt der Module staunen. So ist es sehr einfach z.B. einen Höhensensor zu integrieren (BMP085). Ein Variometer ist etwas schwieriger zu realiseren, weil man am Besten einen genaueren Sensor als den BMP085 benutzt und etwas mehr rechnen muss. Temperaturen lassen sich dafür wieder sehr einfach messen. Auch GPS-Module kann man fertig kaufen und damit z.B. die absolute Höhe, Geschwindigkeit über Grund, Abstand und Winkel zum Piloten etc. berechnen. Mit einem SD-Kartenleser kann man auch die Daten auf dem Sensorbus protokollieren um sie später am PC auswerten zu können (Datenlogger).
Der Arduino kann aber nicht nur im Rahmen der Telemetrie eingesetzt werden. Es gibt fertige Bibliotheken mit denen man z.B. Modellbau-Servos ansteuern kann. Damit ist es möglich z.B. komplexe Bewegungsabläufe zu realisieren (Fahrwerk langsam ein-/ausfahren, anschließend Klappen vom Fahrwerksschacht bewegen, Klapptriebwerke bei Seglern). Oder man schließt ein paar Leuchtdioden an und programmiert sich seine individuelle Modellbeleuchtung.
Aber soweit sind wir noch nicht... Beschäftigen wir uns zunächst etwas mit der Telemetrie. Zunächst schauen wir einfach mal, was sich auf dem Multiplex Sensor Bus so tut. Bei der Gelegenheit das übliche Kleingedruckte:
Für die hier gemachten Anregungen, Schaltungen und Programme übernehme ich natürlich keinerlei Garantie. Bei mir funktioniert alles was ich hier beschreibe - es ist aber nicht ausgeschlossen, dass durch die Nutzung dieser Informationen Schäden an der verwendeten Hardware entstehen. Also: Alles ohne Gewähr und auf eigene Verantwortung...
Das erste Experiment ist ein einfaches Protokoll der Daten auf dem Sensorbus. Hierzu nutzen wir die standardmäßig in der Arduino Entwicklungsumgebung enthaltene SoftwareSerial library, damit wir die serielle Hardwareschnittstelle für die Kommunikation mit dem PC frei halten. Dabei möchten wir nicht nur die Daten protokollieren sondern auch wie das Timing auf dem Bus abläuft. Hilfreich ist es, wenn man vorher bei Multiplex die Spezifikation des MSB® anfordert (das dauert in der Regel einige Tage). Das erleichtert die Interpretation der Daten enorm. Ich werde den Inhalt dieser Spezifikation hier nicht im Detail wiedergeben sondern teilweise auf dieses Dokument verweisen.
Arduino Programme (in der Arduinowelt nennt man sie Sketches) sind sehr einfach aufgebaut. Am Anfang des Programms definiert man welche globale Objekte man benötigt. Dann folgt eine Funktion setup in der man die Hardware konfiguriert. Anschließend führt der Microcontroller in einer unendlichen Schleife die funktion loop aus in der man die eigentliche Arbeit verrichten lassen kann. Für unsere erste Analyse sparen wir uns die loop-Funktion. Wir möchten einfach nur die ersten 250 Bytes auf dem MSB® lesen, jeweils festhalten wann ein Byte angekommen ist und diese Daten dann über die serielle Hardwareschnittstelle (angeschlossen am USB Port des PCs) anzeigen. Wir machen das einfach in zwei Schritten: 1. Aufzeichnen, 2. Daten an den PC übertragen. Einfache Grundkenntnisse in der allgemeinen Programmierung setze ich hier voraus. Auch etwas Vorbeschäftigung mit dem Arduino kann nicht schaden. Man sollte zumindest in der Lage sein einfache Sketches zu schreiben, zu verstehen und zum Laufen zu bringen. Anleitungen hierzu gibt es in Massen im Netz oder auch in gedruckter Form als Buch käuflich zu erwerben.
Aber fangen wir einfach mal an:
Nicht schön, aber funktional...
Dieses kleine Programm laden wir nun aus der Arduino Entwicklungsumgebung auf den Microcontroller (Strg-U). Pin 2 der digitalen I/O-Pins schließen wir an die Signalleitung eines M-Link® Telemetrieempfängers an. Zusätzlich müssen wir noch die Masseleitung des Empfängers mit einem Masseanschluß des Arduino verbinden. Um den Empfänger mit Strom zu versorgen können wir auch noch eine der Vcc-Leitungen des Arduino mit einem Plus-Anschluss (mittlerer Pin) am Empfänger verbinden. Die Multiplex-Empfänger laufen auch mit 3,3 Volt ohne Probleme. Wenn wir keine weiteren Sensoren angeschlossen haben, muss der Empfänger mit der neuesten Firmware von Multiplex ausgestattet sein, damit er seine internen Sensordaten über den Sensorbus nach außen meldet. Ältere Firmware macht das nicht.
In der Arduino Entwicklungsumgebung können wir nun den Serial Monitor aufrufen. Nach kurzer Zeit erscheinen eine Menge Zahlen im Fenster. So sieht das dann zum Beispiel aus (die roten Linien und Texte sind Kommentare von mir):
Das Programm gibt in jeder Zeile das empfangene Datenbyte in 3 Versionen (Dezimal, Hexadezimal und Binär) aus. Am Ende der Zeile folgt die Dauer der Pause in der vor diesem Byte keine Daten empfangen wurden. Der Wert 260 der hierbei abgezogen wird entspricht der Übertragszeit eines Bytes in Microsekunden (bei der verwendeten Übertragungsgeschwindigkeit von 38400 Baud).
Wir erkennen sofort, dass die Daten in einzelnen Blöcken übertragen werden. Zwischen den Blöcken gibt es länger und kürzere Pausen. Der Spezifikation entnehmen wir, dass der Empfänger etwa alle 6 Millisekunden einen Sensor abfragt (in Wirklichkeit etwa alle 5460 Microsekunden) indem er die Adresse des Sensors (0-15) auf den Bus schreibt. Der Sensor antwortet dann mit einem Datenpaket. Falls auf dieser Adresse kein Sensor angeschlossen ist gibt es natürlich auch keine Antwort. Im Beispiel sind nur die Sensoradressen 0 (Empfängerspannung in Volt, hier 3,4 Volt) und 1 (Übertragungsqualität %LQI, hier 0 Prozent weil der Sender ausgeschaltet war) durch den Empfänger belegt.
Man sieht sehr schön, wie der Empfänger die Adressen durchzählt (0 bis 15). Auch ohne die Spezifikation erkennt man recht leicht wie die Daten aufgebaut sind - man kann ja die Sensorwerte parallel dazu auf dem Senderdisplay ablesen und vergleichen wo sich die Bitfolgen wiederfinden. Mit Spezifikation ist es aber natürlich deutlich einfacher...
Die Sensoren liefern immer 3 Datenbytes. Im ersten Byte werden die Sensoradresse und der Datentyp gesendet. Die nächsten beiden Bytes enthalten den eigentlich Wert und ein Flag für den Alarm. Die verwendeten Werteklassen und -bereiche sollte man der jeweils aktuellen Spezifikation entnehmen - da können jederzeit Änderungen/Neuerungen auftauchen (so gibt es zum Beispiel seit der Version 2 der Spezifikation die Möglichkeit Drehzahlen alternativ mit 10 rpm statt vorher mit 100 rpm Genauigkeit zu übertragen).
Soweit - so einfach. Eigentlich... Es gibt da aber einige kleine Stolperfallen. So halten sich offenbar nicht alle verfügbaren Sensoren genau an die Spezifikation von Multiplex. Insbesondere die "kurzen" Pausen zwischen Adresse und Datenpaket werden nicht immer eingehalten (wie man sieht auch nicht vom Multiplex Empfänger selbst - die "kurze Pause" (Multiplex nennt sie Idle Line Timeout) ist viel länger als in der Spezifikation vorgesehen). Oder diese Pausen sind länger als sie gemäß der Spezifikation sein dürften. Manche Sensoren antworten auch nicht auf jede Anfrage, weil sie intern offenbar manchmal zu beschäftigt sind. Dennoch tragen auch solche Sensoren häufig das MSB®-Logo und sind damit von Multiplex als "kompatibel zu M-Link®" ausgezeichnet. So lange nur ein "Master" - der M-Link® Empfänger - am MSB® mitliest ist das auch unkritisch. Der Empfänger kann ja unterscheiden ob das letzte Byte eine Adressanfrage war oder nicht - er hat es ja selbst gesendet. Sobald aber andere Geräte am Bus hängen und die Daten interpretieren möchten wird es schwieriger. Ich bin schon gespannt wie das mit dem von Multiplex angekündigten Datenlogger aussehen wird. Da besteht ein gewisses Risiko das dieser nicht mit allen Fremdsensoren problemlos funktioniert.
Es ist aber kein allzu großes Problem die Spezifikation von Multiplex entsprechend "umzuinterpretieren" und die Mängel solcher Sensoren auszugleichen. Allerdings muss man sich dann darauf verlassen, dass der Empfänger die Sensordaten nicht häufiger als ca. alle 6 Millisekunden abfragt - man orientiert sich also einfach an der "langen Pause". Nach dieser sieht man auf dem MSB® entweder 1 Byte - wenn kein Sensor auf dieser Adresse antwortet - oder eben 4 Bytes. Anschließend kommt wieder eine lange Pause. Wenn sich die Sensoren innerhalb der Spezifikation bewegen, dann ist die Pause mindestens ca. 4,4 ms lang. Senden die Sensoren zu schnell, dann kann sie auch länger dauern. Senden die Sensoren zu langsam, dann auch kürzer... Bei meinen Versuchen werte ich jede Pause von mehr als 3,5 ms als "lange Pause" - und das funktioniert bisher mit allen Sensoren die mir vorliegen.
Aber auch wenn es funktioniert ist es natürlich äußerst unbefriedigend, wenn man so "an der Spezifikation vorbei" programmieren muss um die gewünschte Funktionalität zu erreichen. Wenn Multiplex sich nun zum Beispiel entschließen würde die Abfragefrequenz zu erhöhen wird diese Vorgehensweise nicht mehr funktionieren. Wenn man sich streng an die Spezifikation hält allerdings auch nicht - weil (siehe oben) - es auch Multiplex nicht so genau nimmt mit dem Timing...
Meine Erfahrungen mit dem Multiplex Sensor Bus beschränken sich natürlich auf die Hardware die ich vorliegen habe. Insofern bin ich immer daran interessiert zu sehen wie sich andere Sensoren verhalten. Wer mag kann das Verhalten der Sensoren gerne mit dem o.a. Sketch untersuchen und mir zusenden. Ich freue mich über jede Rückmeldung.
M-Link® und MSB® sind eingetragene Warenzeichen der Multiplex Modellsport GmbH & Co KG
Wenn man mit dem Arduino entwickeln möchte braucht man natürlich erstmal ein wenig Hard- und Software. Für Experimente mit dem Multiplex M-Link® System ist es praktisch, wenn man eine Hardware benutzt die mit 3,3 Volt arbeite kann, da die Pegel auf dem Multiplex Sensor Bus ebenfalls 3,3 Volt betragen. Leider arbeiten die meisten dieser Arduinos bei 3,3 Volt nur mit 8 MHz Taktfrequenz für den Prozessor. Mehr Rechenleistung kann aber nie schaden. Daher habe ich mich für einen Iteaduino entschieden. Das ist ein Arduino Board welches man zwischen 3,3 Volt und 5 Volt umschalten kann - und es läuft in beiden Fällen mit 16 MHz.
Für die ersten Experimente habe ich mir zusätzlich einige preiswerte Komponenten gekauft:
- Einen Joystick als Eingabemedium
- Ein LCDisplay "Nokia 5110 LCD" mit 48x84 Pixeln Auflösung
- Einen kleine Piezo Summer
- Einen SD/Micro SD Kartenleser
So sieht meine erste kleine Hardwaresammlung dann aus (alles bereits an den Arduino angeschlossen):
Für die Zusatzhardware benötigt man teilweise noch passende Bibliotheken damit der Arduino die Hardware auch ansteuern und nutzen kann. Für das Display findet sich zum Beispiel hier eine gute Übersicht über die Funktionsweise sowie ein Download Link für die passende Library. Zum Umgang mit den SD Kartenleser finden sich hier alle nötigen Informationen.
Mit den von mir ausgewählten Komponenten kann ich im Prinzip alles machen, was ich mir so vorstelle. Es gibt sicherlich Spielraum nach oben. Beispielsweise sind auch deutlich leistungsfähigere LC-Display verfügbar - sogar mit Touchscreen. Es gibt auch fertige Tastenfelder als Alternative zum Joystick. Die Soundausgabe ist mit dem Piezosummer natürlich auch etwas eingeschränkt. Komplexe Tonfolgen oder gar Sprachausgabe sind damit wohl nicht so einfach möglich. Aber auch hierfür gibt es Möglichkeiten - bis hin zum kompletten MP3 Player den man an einen Arduino ankoppeln und kontrollieren kann. Sogar fertige Module zur Sprachausgabe sind verfügbar (z.B. Speakjet).
Einfach mal google anwerfen und über die unglaubliche Vielfalt der Module staunen. So ist es sehr einfach z.B. einen Höhensensor zu integrieren (BMP085). Ein Variometer ist etwas schwieriger zu realiseren, weil man am Besten einen genaueren Sensor als den BMP085 benutzt und etwas mehr rechnen muss. Temperaturen lassen sich dafür wieder sehr einfach messen. Auch GPS-Module kann man fertig kaufen und damit z.B. die absolute Höhe, Geschwindigkeit über Grund, Abstand und Winkel zum Piloten etc. berechnen. Mit einem SD-Kartenleser kann man auch die Daten auf dem Sensorbus protokollieren um sie später am PC auswerten zu können (Datenlogger).
Der Arduino kann aber nicht nur im Rahmen der Telemetrie eingesetzt werden. Es gibt fertige Bibliotheken mit denen man z.B. Modellbau-Servos ansteuern kann. Damit ist es möglich z.B. komplexe Bewegungsabläufe zu realisieren (Fahrwerk langsam ein-/ausfahren, anschließend Klappen vom Fahrwerksschacht bewegen, Klapptriebwerke bei Seglern). Oder man schließt ein paar Leuchtdioden an und programmiert sich seine individuelle Modellbeleuchtung.
Aber soweit sind wir noch nicht... Beschäftigen wir uns zunächst etwas mit der Telemetrie. Zunächst schauen wir einfach mal, was sich auf dem Multiplex Sensor Bus so tut. Bei der Gelegenheit das übliche Kleingedruckte:
Für die hier gemachten Anregungen, Schaltungen und Programme übernehme ich natürlich keinerlei Garantie. Bei mir funktioniert alles was ich hier beschreibe - es ist aber nicht ausgeschlossen, dass durch die Nutzung dieser Informationen Schäden an der verwendeten Hardware entstehen. Also: Alles ohne Gewähr und auf eigene Verantwortung...
Das erste Experiment ist ein einfaches Protokoll der Daten auf dem Sensorbus. Hierzu nutzen wir die standardmäßig in der Arduino Entwicklungsumgebung enthaltene SoftwareSerial library, damit wir die serielle Hardwareschnittstelle für die Kommunikation mit dem PC frei halten. Dabei möchten wir nicht nur die Daten protokollieren sondern auch wie das Timing auf dem Bus abläuft. Hilfreich ist es, wenn man vorher bei Multiplex die Spezifikation des MSB® anfordert (das dauert in der Regel einige Tage). Das erleichtert die Interpretation der Daten enorm. Ich werde den Inhalt dieser Spezifikation hier nicht im Detail wiedergeben sondern teilweise auf dieses Dokument verweisen.
Arduino Programme (in der Arduinowelt nennt man sie Sketches) sind sehr einfach aufgebaut. Am Anfang des Programms definiert man welche globale Objekte man benötigt. Dann folgt eine Funktion setup in der man die Hardware konfiguriert. Anschließend führt der Microcontroller in einer unendlichen Schleife die funktion loop aus in der man die eigentliche Arbeit verrichten lassen kann. Für unsere erste Analyse sparen wir uns die loop-Funktion. Wir möchten einfach nur die ersten 250 Bytes auf dem MSB® lesen, jeweils festhalten wann ein Byte angekommen ist und diese Daten dann über die serielle Hardwareschnittstelle (angeschlossen am USB Port des PCs) anzeigen. Wir machen das einfach in zwei Schritten: 1. Aufzeichnen, 2. Daten an den PC übertragen. Einfache Grundkenntnisse in der allgemeinen Programmierung setze ich hier voraus. Auch etwas Vorbeschäftigung mit dem Arduino kann nicht schaden. Man sollte zumindest in der Lage sein einfache Sketches zu schreiben, zu verstehen und zum Laufen zu bringen. Anleitungen hierzu gibt es in Massen im Netz oder auch in gedruckter Form als Buch käuflich zu erwerben.
Aber fangen wir einfach mal an:
// Die Verwendung der library SoftwareSerial vorbereiten #includeSoftwareSerial msb(2,3); // Pin2 an MSB anschließen, Pin 3 offen lassen uint8_t buf[250]; // Der Zwischenspeicher für die MSB-Daten unsigned long buftime[250]; // Der Zwischenspeicher für die Zeitstempel int bufp=0; // Hier merken wir uns wieviel Daten wir bereits empfangen habe // Hier passiert alle Arbeit void setup() { Serial.begin(115200); // Serielle Schnittstelle zum PC initialisieren msb.begin(38400); // MSB Initialisieren // 250 Byte lesen while (bufp<250) { if (msb.available()) { buftime[bufp]=micros(); // Mircosekunden seit start merken buf[bufp++]=msb.read(); // Datenbyte merken } } // Ergebnisse über die serielle Schnittstelle ausgeben for (bufp=1; bufp<250; bufp++) { Serial.print((int) buf[bufp]); // Byte ausgeben Serial.print(" "); // Ein paar Leerzeichen Serial.print((int) buf[bufp],HEX); // Hexadezimal Serial.print(" "); // Ein paar Leerzeichen Serial.print((int) buf[bufp],BIN); // Hexadezimal Serial.print(" "); // Ein paar Leerzeichen zwischen Byte und Zeitstempel Serial.println(buftime[bufp]-buftime[bufp-1]-260); // Zeit ausgeben seit letztem Byte } } // Im loop machen wir überhaupt nichts void loop() { }
Dieses kleine Programm laden wir nun aus der Arduino Entwicklungsumgebung auf den Microcontroller (Strg-U). Pin 2 der digitalen I/O-Pins schließen wir an die Signalleitung eines M-Link® Telemetrieempfängers an. Zusätzlich müssen wir noch die Masseleitung des Empfängers mit einem Masseanschluß des Arduino verbinden. Um den Empfänger mit Strom zu versorgen können wir auch noch eine der Vcc-Leitungen des Arduino mit einem Plus-Anschluss (mittlerer Pin) am Empfänger verbinden. Die Multiplex-Empfänger laufen auch mit 3,3 Volt ohne Probleme. Wenn wir keine weiteren Sensoren angeschlossen haben, muss der Empfänger mit der neuesten Firmware von Multiplex ausgestattet sein, damit er seine internen Sensordaten über den Sensorbus nach außen meldet. Ältere Firmware macht das nicht.
In der Arduino Entwicklungsumgebung können wir nun den Serial Monitor aufrufen. Nach kurzer Zeit erscheinen eine Menge Zahlen im Fenster. So sieht das dann zum Beispiel aus (die roten Linien und Texte sind Kommentare von mir):
Das Programm gibt in jeder Zeile das empfangene Datenbyte in 3 Versionen (Dezimal, Hexadezimal und Binär) aus. Am Ende der Zeile folgt die Dauer der Pause in der vor diesem Byte keine Daten empfangen wurden. Der Wert 260 der hierbei abgezogen wird entspricht der Übertragszeit eines Bytes in Microsekunden (bei der verwendeten Übertragungsgeschwindigkeit von 38400 Baud).
Wir erkennen sofort, dass die Daten in einzelnen Blöcken übertragen werden. Zwischen den Blöcken gibt es länger und kürzere Pausen. Der Spezifikation entnehmen wir, dass der Empfänger etwa alle 6 Millisekunden einen Sensor abfragt (in Wirklichkeit etwa alle 5460 Microsekunden) indem er die Adresse des Sensors (0-15) auf den Bus schreibt. Der Sensor antwortet dann mit einem Datenpaket. Falls auf dieser Adresse kein Sensor angeschlossen ist gibt es natürlich auch keine Antwort. Im Beispiel sind nur die Sensoradressen 0 (Empfängerspannung in Volt, hier 3,4 Volt) und 1 (Übertragungsqualität %LQI, hier 0 Prozent weil der Sender ausgeschaltet war) durch den Empfänger belegt.
Man sieht sehr schön, wie der Empfänger die Adressen durchzählt (0 bis 15). Auch ohne die Spezifikation erkennt man recht leicht wie die Daten aufgebaut sind - man kann ja die Sensorwerte parallel dazu auf dem Senderdisplay ablesen und vergleichen wo sich die Bitfolgen wiederfinden. Mit Spezifikation ist es aber natürlich deutlich einfacher...
Die Sensoren liefern immer 3 Datenbytes. Im ersten Byte werden die Sensoradresse und der Datentyp gesendet. Die nächsten beiden Bytes enthalten den eigentlich Wert und ein Flag für den Alarm. Die verwendeten Werteklassen und -bereiche sollte man der jeweils aktuellen Spezifikation entnehmen - da können jederzeit Änderungen/Neuerungen auftauchen (so gibt es zum Beispiel seit der Version 2 der Spezifikation die Möglichkeit Drehzahlen alternativ mit 10 rpm statt vorher mit 100 rpm Genauigkeit zu übertragen).
Soweit - so einfach. Eigentlich... Es gibt da aber einige kleine Stolperfallen. So halten sich offenbar nicht alle verfügbaren Sensoren genau an die Spezifikation von Multiplex. Insbesondere die "kurzen" Pausen zwischen Adresse und Datenpaket werden nicht immer eingehalten (wie man sieht auch nicht vom Multiplex Empfänger selbst - die "kurze Pause" (Multiplex nennt sie Idle Line Timeout) ist viel länger als in der Spezifikation vorgesehen). Oder diese Pausen sind länger als sie gemäß der Spezifikation sein dürften. Manche Sensoren antworten auch nicht auf jede Anfrage, weil sie intern offenbar manchmal zu beschäftigt sind. Dennoch tragen auch solche Sensoren häufig das MSB®-Logo und sind damit von Multiplex als "kompatibel zu M-Link®" ausgezeichnet. So lange nur ein "Master" - der M-Link® Empfänger - am MSB® mitliest ist das auch unkritisch. Der Empfänger kann ja unterscheiden ob das letzte Byte eine Adressanfrage war oder nicht - er hat es ja selbst gesendet. Sobald aber andere Geräte am Bus hängen und die Daten interpretieren möchten wird es schwieriger. Ich bin schon gespannt wie das mit dem von Multiplex angekündigten Datenlogger aussehen wird. Da besteht ein gewisses Risiko das dieser nicht mit allen Fremdsensoren problemlos funktioniert.
Es ist aber kein allzu großes Problem die Spezifikation von Multiplex entsprechend "umzuinterpretieren" und die Mängel solcher Sensoren auszugleichen. Allerdings muss man sich dann darauf verlassen, dass der Empfänger die Sensordaten nicht häufiger als ca. alle 6 Millisekunden abfragt - man orientiert sich also einfach an der "langen Pause". Nach dieser sieht man auf dem MSB® entweder 1 Byte - wenn kein Sensor auf dieser Adresse antwortet - oder eben 4 Bytes. Anschließend kommt wieder eine lange Pause. Wenn sich die Sensoren innerhalb der Spezifikation bewegen, dann ist die Pause mindestens ca. 4,4 ms lang. Senden die Sensoren zu schnell, dann kann sie auch länger dauern. Senden die Sensoren zu langsam, dann auch kürzer... Bei meinen Versuchen werte ich jede Pause von mehr als 3,5 ms als "lange Pause" - und das funktioniert bisher mit allen Sensoren die mir vorliegen.
Aber auch wenn es funktioniert ist es natürlich äußerst unbefriedigend, wenn man so "an der Spezifikation vorbei" programmieren muss um die gewünschte Funktionalität zu erreichen. Wenn Multiplex sich nun zum Beispiel entschließen würde die Abfragefrequenz zu erhöhen wird diese Vorgehensweise nicht mehr funktionieren. Wenn man sich streng an die Spezifikation hält allerdings auch nicht - weil (siehe oben) - es auch Multiplex nicht so genau nimmt mit dem Timing...
Meine Erfahrungen mit dem Multiplex Sensor Bus beschränken sich natürlich auf die Hardware die ich vorliegen habe. Insofern bin ich immer daran interessiert zu sehen wie sich andere Sensoren verhalten. Wer mag kann das Verhalten der Sensoren gerne mit dem o.a. Sketch untersuchen und mir zusenden. Ich freue mich über jede Rückmeldung.
M-Link® und MSB® sind eingetragene Warenzeichen der Multiplex Modellsport GmbH & Co KG
Multiplex M-Link - Stärken und Schwächen
Als ich vor einiger Zeit auf der Suche nach einem modernen RC-System war bin ich auf das M-Link® System von Multiplex gestoßen. Multiplex konnte als erster großer Hersteller ein komplettes System aus Sendern und Empfängern mit Telemetriefähigkeiten sowie eine umfangreiche Sensorik anbieten. Als bekannteste Alternative gab es noch das Jeti-System. Auch hier war Telemetrie möglich - allerdings musste man hierzu ein Jeti-Modul in einen RC-Sender einbauen. Eine komplette Lösung aus einer Hand war dabei nicht verfügbar.
Besonders "nett" fand ich es, dass Multiplex alle Informationen zum Anschluss von Sensoren offenlegt. Damit ist die Tür für Fremdhersteller offen um eigene Sensorik an das System anzukoppeln. Diese Möglichkeit wurde auch sehr schnell genutzt - beispielsweise von der Firma SM-Modellbau die ihren bekannten Datenlogger mit einer Schnittstelle zum M-Link® Sensorbus ausstattete. Damit stand sehr bald ein kompakter Multisensor zur Verfügung mit dem man z.B. Höhe, Temperaturen, Drehzahlen, Spannung und Strom in einem kompakten Gehäuse protokollieren und die wichtigsten Werte per Telemetrie übertragen konnte. Und das zu einem erstaunlich geringen Preis.
Die Verfügbarkeit des Unilog hat mich damals endgültig überzeugt nachdem Multiplex zu diesem Zeitpunkt gerade mit der Auslieferung des telemetriefähigen Senders Cockpit SX begann. Ich habe mir also diesen Sender gekauft und bin nach wie vor sehr zufrieden damit.
Womit wir schon mal bei den Vorteilen währen:
Zuverlässigkeit
Was kann man hierzu sagen? M-Link® funktioniert halt einfach. Ich hatte noch nie auch nur ansatzweise Probleme mit der Funkstrecke. Keine einzige Störung. Keine Funkaussetzer. Auch der Fehlerzähler in meinen Empfängern hat noch nie auch nur einen einzigen Fehler angezeigt. Das ist zunächst mal die wichtigste Eigenschaft eines RC-Systems. Störungen können schließlich das Modell kosten.
Produktpalette
Multiplex bietet eine relativ breite Produktpalette an. Sowohl bei den Sendern als auch bei Empfängern und Sensorik. Man findet fast alles was man braucht. Der Rest wird von Fremdherstellern abgedeckt. Besonders gelungen ist - spätestens seit der Spielwarenmesse in Nürnberg 2012 - die Palette an Empfängern. Vom Microempfänger bis zum großen Profiempfänger ist alles dabei. Teilweise mit doppelt ausgelegtem Empfangsteil und zwei Antennen. Zusätzlich gibt es die Möglichkeit mehrere Empfänger zu koppeln um eine noch höhere Zuverlässigkeit zu erreichen. Das passt einfach.
Stromverbrauch
Offenbar braucht das HF-Teil zumindest in der Cockpit SX sehr wenig Strom. Die Betriebszeit mit dem mitgelieferten Senderakku reicht norrmalerweise für mehrere Flugtage. Selbst beim Segelflug wo Flugzeiten von mehreren Stunden ja nicht außergewöhnlich sind.
Kompatibilität
Hier hat Multiplex sich sehr viel Mühe gegeben damit die Besitzer älterer 35 Mhz-Sender auch in den Genuß der Vorteile von M-Link® kommen. Man kann selbst uralte Sender (und auch Sender von Fremdherstellern) auf M-Link® umrüsten. Im Fall der RoyalPro-Sender sogar inklusive Darstellung der Temeletriedaten auf dem internen Senderdisplay.
Ergonomie
Offenbar macht Multiplex sich recht viele Gedanken über die Ergonomie der Sender. Die Cockpit SX gefällt mir da zum Beispiel ausnehmen gut. Insbesondere die beiden Proportionalgeber links und rechts oben sind einfach gelungen. Sie lassen sich wahlweise mit Daumen oder Zeigefinger bedienen. Egal ob als Handsender oder im Senderpult - die Geber sind immer gut zugreifbar. Das finde ich in dieser Ausführung einfach genial.
Im Laufe der Zeit habe (nicht nur) ich aber auch einige Schwächen an der M-Link® Telemetrie erkannt:
Auflösung
Insbesondere bei der Übertragung von Drehzahlen ist es - zumindest beim RC-Hubschrauber - sehr ärgerlich, dass die Drehzahlen nur mit einer Auflösung von 100 rpm übertragen wurden. Man sieht im Display also nur 2200 rpm oder 2300 rpm - Zwischenwerte gibt es keine. Mittlerweile hat Multiplex hier nachgebessert und eine Auflösung von 10 rpm im Sensorprotokoll nachgeliefert. Das wird aber leider noch nicht von allen Sensoren unterstützt.
Auch bei der Spannungsmessung wäre manchmal eine etwas höhere Auflösung wünschenswert. Bei Ladegeräten ist es zum Beispiel Standard, dass die Zellenspannung eines Lipos auf 1/100tel Volt genau gemessen wird. M-Link® bietet hier nur 1/10tel Volt. In der Regel kann man aber mit dieser Auflösung leben.
Benennung
Es gibt aktuell keine Möglichkeit die Sensoren zu benennen. Hat man beispielsweise mehrere Spannungs- oder Temperatursensoren im Modell, so muss man sich selbst merken welcher Sensor mit welcher Adresse sendet. Sehr viel praktischer wäre es natürlich, wenn man aussagekräftige Bezeichnungen hätte. Der auf der Nürnberger Spielwarenmesse angekündigte neue Profi Pultsender von Multiplex scheint sowas immerhin zu bieten. Das mittlerweile lieferbare externe Telemetrie-Display für ältere Sender leider nicht.
Akustische Meldungen der Sensorik
Hier lauert in meinen Augen die größte Schwäche der aktuellen Implementierung von M-Link®. Alarme werden derzeit von den Sendern nur einmalig akustisch über eine kurze Tonfolge gemeldet. Das ist schlicht nicht praxisgerecht. Zu leicht überhört man den Alarm und riskiert in der Folge zum Beispiel durch nachlassende Akkuleistung das Modell. Es gibt auch keine Unterscheidungsmöglichkeit zwischen unterschiedlich wichtigen Alarmen. Immerhin wird es bald eine externe Sprachausgabe als Zusatzgerät geben. Besser wäre aber eine Integration in die Sender und im Fall wichtiger Alarme eine akustische Warnung die vom Benutzer z.B. durch einen Schalter abgeschaltete werden muss. Erst damit wäre sichergestellt, dass die Alarme den Modellpiloten auch erreichen.
Leider bekommt ein Sensor auch nicht mit wenn ein Alarm am Boden angekommen ist. Hier obliegt es den Sensorentwicklern Alarme die ggf. nur kurz auftreten auf einen längeren Zeitraum zu strecken um wenigstens einigermaßen sicher zu sein dass der Alarm den Piloten auch wirklich erreicht.
Erkennung eines unterbrochenen Downlinks
Aktuell scheint der Sender nicht erkennen zu können ob die Übertragung der Telemetriedaten ausgefallen ist - also ob der Downlink funktioniert oder nicht. Meine Cockpit SX zeigt in diesem Fall zum Beispiel munter die letzten empfangenen Telemetriewerte an. Es gibt keinerlei Warnung wenn der Downlink ausfällt. Das bedeutet aber das dem Piloten eine trügerische Sicherheit vorgespiegelt wird. Mit einem Blick auf das Display glaubt man zum Beispiel die aktuelle Akkuspannung zu kennen und beruhigt weiterfliegen zu können. Dabei ist der Wert ggf. völlig veraltet und das Modell ist längst in Gefahr.
Mit dem externen Telemetrie-Display gibt es neuerdings immerhin eine Anzeige des ausgefallenen Downlinks. Die Werte werden dann durchgestrichen.
Lösungen
Für die meisten der angesprochenen Nachteile lassen sich mehr oder weniger leicht Lösungen finden. So gibt es mittlerweile eine Kopplung des HF-Moduls im Sender mit einer Sprachausgabe von mindestens zwei Herstellern. Damit ist zumindest die Nicht-Unterscheidbarkeit der Alarme gemildert und das Ganze passiert direkt im Sender ohne unhandliche Zusatzgeräte. Eine Wiederholung der Alarme lässt sich direkt in die Sensoren integrieren - hier wären die Hersteller der Sensorik gefragt. Man kann aber auch ein kleines Modul basteln mit dem man am MSB® mithört und die Alarme dann "aufbereitet" auf einer anderen Adresse wiederholt. Schaltet man dabei den Alarm z.B. im Takt von 1 oder 2 Sekunden ein und aus, piepst der Sender entsprechend dauerhaft. Schließt man diesen Pseudo-Sensor dann noch an einen Empfängerkanal an, könnte man ihm auch eine Quittung übermitteln um den Alarm abzuschalten.
Solch ein Modul ist mit dem Arduino recht einfach zu entwickeln. Im Rahmen dieses Blogs werde ich zeigen wie das funktionieren kann. Damit kann man dann auch die Sensoren jenseits der Sensoradresse 7 im Alarmfall auf eine Adresse 0-7 umleiten so dass auch die Cokpit SX diese Alarme darstellen kann.
M-Link® und MSB® sind eingetragene Warenzeichen der Multiplex Modellsport GmbH & Co KG
Besonders "nett" fand ich es, dass Multiplex alle Informationen zum Anschluss von Sensoren offenlegt. Damit ist die Tür für Fremdhersteller offen um eigene Sensorik an das System anzukoppeln. Diese Möglichkeit wurde auch sehr schnell genutzt - beispielsweise von der Firma SM-Modellbau die ihren bekannten Datenlogger mit einer Schnittstelle zum M-Link® Sensorbus ausstattete. Damit stand sehr bald ein kompakter Multisensor zur Verfügung mit dem man z.B. Höhe, Temperaturen, Drehzahlen, Spannung und Strom in einem kompakten Gehäuse protokollieren und die wichtigsten Werte per Telemetrie übertragen konnte. Und das zu einem erstaunlich geringen Preis.
Die Verfügbarkeit des Unilog hat mich damals endgültig überzeugt nachdem Multiplex zu diesem Zeitpunkt gerade mit der Auslieferung des telemetriefähigen Senders Cockpit SX begann. Ich habe mir also diesen Sender gekauft und bin nach wie vor sehr zufrieden damit.
Womit wir schon mal bei den Vorteilen währen:
Zuverlässigkeit
Was kann man hierzu sagen? M-Link® funktioniert halt einfach. Ich hatte noch nie auch nur ansatzweise Probleme mit der Funkstrecke. Keine einzige Störung. Keine Funkaussetzer. Auch der Fehlerzähler in meinen Empfängern hat noch nie auch nur einen einzigen Fehler angezeigt. Das ist zunächst mal die wichtigste Eigenschaft eines RC-Systems. Störungen können schließlich das Modell kosten.
Produktpalette
Multiplex bietet eine relativ breite Produktpalette an. Sowohl bei den Sendern als auch bei Empfängern und Sensorik. Man findet fast alles was man braucht. Der Rest wird von Fremdherstellern abgedeckt. Besonders gelungen ist - spätestens seit der Spielwarenmesse in Nürnberg 2012 - die Palette an Empfängern. Vom Microempfänger bis zum großen Profiempfänger ist alles dabei. Teilweise mit doppelt ausgelegtem Empfangsteil und zwei Antennen. Zusätzlich gibt es die Möglichkeit mehrere Empfänger zu koppeln um eine noch höhere Zuverlässigkeit zu erreichen. Das passt einfach.
Stromverbrauch
Offenbar braucht das HF-Teil zumindest in der Cockpit SX sehr wenig Strom. Die Betriebszeit mit dem mitgelieferten Senderakku reicht norrmalerweise für mehrere Flugtage. Selbst beim Segelflug wo Flugzeiten von mehreren Stunden ja nicht außergewöhnlich sind.
Kompatibilität
Hier hat Multiplex sich sehr viel Mühe gegeben damit die Besitzer älterer 35 Mhz-Sender auch in den Genuß der Vorteile von M-Link® kommen. Man kann selbst uralte Sender (und auch Sender von Fremdherstellern) auf M-Link® umrüsten. Im Fall der RoyalPro-Sender sogar inklusive Darstellung der Temeletriedaten auf dem internen Senderdisplay.
Ergonomie
Offenbar macht Multiplex sich recht viele Gedanken über die Ergonomie der Sender. Die Cockpit SX gefällt mir da zum Beispiel ausnehmen gut. Insbesondere die beiden Proportionalgeber links und rechts oben sind einfach gelungen. Sie lassen sich wahlweise mit Daumen oder Zeigefinger bedienen. Egal ob als Handsender oder im Senderpult - die Geber sind immer gut zugreifbar. Das finde ich in dieser Ausführung einfach genial.
Im Laufe der Zeit habe (nicht nur) ich aber auch einige Schwächen an der M-Link® Telemetrie erkannt:
Auflösung
Insbesondere bei der Übertragung von Drehzahlen ist es - zumindest beim RC-Hubschrauber - sehr ärgerlich, dass die Drehzahlen nur mit einer Auflösung von 100 rpm übertragen wurden. Man sieht im Display also nur 2200 rpm oder 2300 rpm - Zwischenwerte gibt es keine. Mittlerweile hat Multiplex hier nachgebessert und eine Auflösung von 10 rpm im Sensorprotokoll nachgeliefert. Das wird aber leider noch nicht von allen Sensoren unterstützt.
Auch bei der Spannungsmessung wäre manchmal eine etwas höhere Auflösung wünschenswert. Bei Ladegeräten ist es zum Beispiel Standard, dass die Zellenspannung eines Lipos auf 1/100tel Volt genau gemessen wird. M-Link® bietet hier nur 1/10tel Volt. In der Regel kann man aber mit dieser Auflösung leben.
Benennung
Es gibt aktuell keine Möglichkeit die Sensoren zu benennen. Hat man beispielsweise mehrere Spannungs- oder Temperatursensoren im Modell, so muss man sich selbst merken welcher Sensor mit welcher Adresse sendet. Sehr viel praktischer wäre es natürlich, wenn man aussagekräftige Bezeichnungen hätte. Der auf der Nürnberger Spielwarenmesse angekündigte neue Profi Pultsender von Multiplex scheint sowas immerhin zu bieten. Das mittlerweile lieferbare externe Telemetrie-Display für ältere Sender leider nicht.
Akustische Meldungen der Sensorik
Hier lauert in meinen Augen die größte Schwäche der aktuellen Implementierung von M-Link®. Alarme werden derzeit von den Sendern nur einmalig akustisch über eine kurze Tonfolge gemeldet. Das ist schlicht nicht praxisgerecht. Zu leicht überhört man den Alarm und riskiert in der Folge zum Beispiel durch nachlassende Akkuleistung das Modell. Es gibt auch keine Unterscheidungsmöglichkeit zwischen unterschiedlich wichtigen Alarmen. Immerhin wird es bald eine externe Sprachausgabe als Zusatzgerät geben. Besser wäre aber eine Integration in die Sender und im Fall wichtiger Alarme eine akustische Warnung die vom Benutzer z.B. durch einen Schalter abgeschaltete werden muss. Erst damit wäre sichergestellt, dass die Alarme den Modellpiloten auch erreichen.
Leider bekommt ein Sensor auch nicht mit wenn ein Alarm am Boden angekommen ist. Hier obliegt es den Sensorentwicklern Alarme die ggf. nur kurz auftreten auf einen längeren Zeitraum zu strecken um wenigstens einigermaßen sicher zu sein dass der Alarm den Piloten auch wirklich erreicht.
Erkennung eines unterbrochenen Downlinks
Aktuell scheint der Sender nicht erkennen zu können ob die Übertragung der Telemetriedaten ausgefallen ist - also ob der Downlink funktioniert oder nicht. Meine Cockpit SX zeigt in diesem Fall zum Beispiel munter die letzten empfangenen Telemetriewerte an. Es gibt keinerlei Warnung wenn der Downlink ausfällt. Das bedeutet aber das dem Piloten eine trügerische Sicherheit vorgespiegelt wird. Mit einem Blick auf das Display glaubt man zum Beispiel die aktuelle Akkuspannung zu kennen und beruhigt weiterfliegen zu können. Dabei ist der Wert ggf. völlig veraltet und das Modell ist längst in Gefahr.
Mit dem externen Telemetrie-Display gibt es neuerdings immerhin eine Anzeige des ausgefallenen Downlinks. Die Werte werden dann durchgestrichen.
Lösungen
Für die meisten der angesprochenen Nachteile lassen sich mehr oder weniger leicht Lösungen finden. So gibt es mittlerweile eine Kopplung des HF-Moduls im Sender mit einer Sprachausgabe von mindestens zwei Herstellern. Damit ist zumindest die Nicht-Unterscheidbarkeit der Alarme gemildert und das Ganze passiert direkt im Sender ohne unhandliche Zusatzgeräte. Eine Wiederholung der Alarme lässt sich direkt in die Sensoren integrieren - hier wären die Hersteller der Sensorik gefragt. Man kann aber auch ein kleines Modul basteln mit dem man am MSB® mithört und die Alarme dann "aufbereitet" auf einer anderen Adresse wiederholt. Schaltet man dabei den Alarm z.B. im Takt von 1 oder 2 Sekunden ein und aus, piepst der Sender entsprechend dauerhaft. Schließt man diesen Pseudo-Sensor dann noch an einen Empfängerkanal an, könnte man ihm auch eine Quittung übermitteln um den Alarm abzuschalten.
Solch ein Modul ist mit dem Arduino recht einfach zu entwickeln. Im Rahmen dieses Blogs werde ich zeigen wie das funktionieren kann. Damit kann man dann auch die Sensoren jenseits der Sensoradresse 7 im Alarmfall auf eine Adresse 0-7 umleiten so dass auch die Cokpit SX diese Alarme darstellen kann.
M-Link® und MSB® sind eingetragene Warenzeichen der Multiplex Modellsport GmbH & Co KG
Udos Modellflug Blog
Hallo!
Mit diesem Blog möchte ich über meine Erfahrungen mit dem RC Modellflug, RC Elektronik und eigenen Entwicklungen schreiben.
Über mich:
Ich wurde 1964 geboren und betreibe - mit einigen Unterbrechungen - Modellflug seit ich 14 Jahre alt bin. Im Moment fliege ich sehr gerne mit Modellhelikoptern - habe aber auch noch (Elektro-)Segler und (Elektro-)Motorflugzeuge.
Für einige Modelle habe ich mir eine Spektrum DX6i gekauft (zum Beispiel für den Blade MCP x oder die UMX Beast). Meine größeren Modelle fliege ich aber mit einer Cockpit SX M-Link® von Multiplex. Ich habe mich vor ca. 1,5 Jahren für das M-Link® System entschieden, weil Multiplex als erster großer Hersteller in der Lage war ein RC-System mit eingebauter Telemetrie anzubieten. Es gab damals zwar schon andere Lösungen aber keine wirkliche Integration von Sender, Empfänger und Telemetrie aus einer Hand. Zudem hat Multiplex das Protokoll der Telemetriesensoren im Modell offen gelegt so dass sehr schnell Sensoren von Fremdherstellern auf den Markt kame.
Allerdings hat die M-Link® Telemetrie in meinen Augen einige Schwachstellen. So muss man Alarmschwellen in den einzelnen Sensoren hinterlegen. Hierzu muss man die Sensoren vom Empfänger trennen und an einen PC anschließen oder - auf dem Feld - die Multiplex Multimate nutzen. Ziemlich unbequem und lästig. Für viele Alarme wäre es sinnvoller, wenn man auf dem Flugfeld schnell und einfach die Alarmschwellen ändern könnte.
Das größte Manko bei der M-Link ® Telemetrie sind aber die Alarme. Derzeit wird ein Alarm nur ein einziges Mal akustisch gemeldet. Wenn ich zum Beispiel eine Warnschwelle bei 2400 mAh entnommener Kapazität aus dem Flugakku einstelle, piepst meine Cockpit SX nur einmal sobald diese 2400 mAh erreicht sind. Wenn ein paar Meter vor mir ein Heli schwebt, stehen die Chancen gut dass ich diesen Alarmton schlicht überhöre. Außerdem ist es derzeit nicht möglich unterschiedliche Alarme mit unterschiedlichen Tönen oder Tonfolgen zu signalisieren. Der Piepser hört sich immer gleich an - egal ob ich "nur" die zulässige Flughöhe überschreite oder ob der Flugakku leer ist.
Der größte Vorteil der Telemetrie im Modellbau ist aber die erhöhte Sicherheit - insbesondere im Bezug auf den Akkuzustand. Wenn man Alarme aber nicht zuverlässig bemerkt, dann ist diese Sicherheit nicht gegeben.
In den letzten Wochen habe ich daher begonnen mit mit der Arduino platform zu beschäftigen. Arduino ist ein Paket aus Hard- und Software rund um die ATmega Microcontroller mit dem man relativ einfach und ohne allzu viele Elektronik-Kenntnisse in der Lage ist Anwendungen für diesen Microcontroller zu entwickeln. Als Hardware verwende ich im Moment einen Iteaduino von ITead Studio - eine etwas verbesserte Variante der Arduino Hardware.
Mit dem Arduino ist es mir in kurzer Zeit gelungen Sensoren zu simulieren die an einen M-Link® Empfänger angeschlossen werden. Derzeit arbeite ich an der "Bodenstation", also einem Display/Soundgenerator mit Anschluss an den Sender bei dem ich die Alarme so auswerten kann wie ich mir das vorstelle. Leider legt Multiplex das Protokoll mit dem der Sender seine Daten nach außen liefert nicht offen, daher bin ich hier auf eine eigene Analyse der Daten angewiesen. Die meisten Daten lassen sich auch recht einfach interpretieren. Einige wenige Informationen fehlen mir noch. Dennoch funktioniert die erste Version meines Displays bereits ganz gut.
Mehr dazu - demnächst an dieser Stelle.
Ciao, Udo
P.S.: Mitstreiter für derartige Projekte sind immer willkommen.
M-Link® und MSB® sind eingetragene Warenzeichen der Multiplex Modellsport GmbH & Co KG
Mit diesem Blog möchte ich über meine Erfahrungen mit dem RC Modellflug, RC Elektronik und eigenen Entwicklungen schreiben.
Über mich:
Ich wurde 1964 geboren und betreibe - mit einigen Unterbrechungen - Modellflug seit ich 14 Jahre alt bin. Im Moment fliege ich sehr gerne mit Modellhelikoptern - habe aber auch noch (Elektro-)Segler und (Elektro-)Motorflugzeuge.
Für einige Modelle habe ich mir eine Spektrum DX6i gekauft (zum Beispiel für den Blade MCP x oder die UMX Beast). Meine größeren Modelle fliege ich aber mit einer Cockpit SX M-Link® von Multiplex. Ich habe mich vor ca. 1,5 Jahren für das M-Link® System entschieden, weil Multiplex als erster großer Hersteller in der Lage war ein RC-System mit eingebauter Telemetrie anzubieten. Es gab damals zwar schon andere Lösungen aber keine wirkliche Integration von Sender, Empfänger und Telemetrie aus einer Hand. Zudem hat Multiplex das Protokoll der Telemetriesensoren im Modell offen gelegt so dass sehr schnell Sensoren von Fremdherstellern auf den Markt kame.
Allerdings hat die M-Link® Telemetrie in meinen Augen einige Schwachstellen. So muss man Alarmschwellen in den einzelnen Sensoren hinterlegen. Hierzu muss man die Sensoren vom Empfänger trennen und an einen PC anschließen oder - auf dem Feld - die Multiplex Multimate nutzen. Ziemlich unbequem und lästig. Für viele Alarme wäre es sinnvoller, wenn man auf dem Flugfeld schnell und einfach die Alarmschwellen ändern könnte.
Das größte Manko bei der M-Link ® Telemetrie sind aber die Alarme. Derzeit wird ein Alarm nur ein einziges Mal akustisch gemeldet. Wenn ich zum Beispiel eine Warnschwelle bei 2400 mAh entnommener Kapazität aus dem Flugakku einstelle, piepst meine Cockpit SX nur einmal sobald diese 2400 mAh erreicht sind. Wenn ein paar Meter vor mir ein Heli schwebt, stehen die Chancen gut dass ich diesen Alarmton schlicht überhöre. Außerdem ist es derzeit nicht möglich unterschiedliche Alarme mit unterschiedlichen Tönen oder Tonfolgen zu signalisieren. Der Piepser hört sich immer gleich an - egal ob ich "nur" die zulässige Flughöhe überschreite oder ob der Flugakku leer ist.
Der größte Vorteil der Telemetrie im Modellbau ist aber die erhöhte Sicherheit - insbesondere im Bezug auf den Akkuzustand. Wenn man Alarme aber nicht zuverlässig bemerkt, dann ist diese Sicherheit nicht gegeben.
In den letzten Wochen habe ich daher begonnen mit mit der Arduino platform zu beschäftigen. Arduino ist ein Paket aus Hard- und Software rund um die ATmega Microcontroller mit dem man relativ einfach und ohne allzu viele Elektronik-Kenntnisse in der Lage ist Anwendungen für diesen Microcontroller zu entwickeln. Als Hardware verwende ich im Moment einen Iteaduino von ITead Studio - eine etwas verbesserte Variante der Arduino Hardware.
Mit dem Arduino ist es mir in kurzer Zeit gelungen Sensoren zu simulieren die an einen M-Link® Empfänger angeschlossen werden. Derzeit arbeite ich an der "Bodenstation", also einem Display/Soundgenerator mit Anschluss an den Sender bei dem ich die Alarme so auswerten kann wie ich mir das vorstelle. Leider legt Multiplex das Protokoll mit dem der Sender seine Daten nach außen liefert nicht offen, daher bin ich hier auf eine eigene Analyse der Daten angewiesen. Die meisten Daten lassen sich auch recht einfach interpretieren. Einige wenige Informationen fehlen mir noch. Dennoch funktioniert die erste Version meines Displays bereits ganz gut.
Mehr dazu - demnächst an dieser Stelle.
Ciao, Udo
P.S.: Mitstreiter für derartige Projekte sind immer willkommen.
M-Link® und MSB® sind eingetragene Warenzeichen der Multiplex Modellsport GmbH & Co KG
Abonnieren
Posts (Atom)