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):
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
Keine Kommentare:
Kommentar veröffentlichen