Ich habe nun beide an JLog2 genagelt, heute bekam ich eine MPX ROYAL pro 7 und konnte die M-Link Telemetrie fertig machen.
Ich betrachte es aus beiden Blickwinkeln, aus Sicht des Implementators, desjenigen, der Sensoren in die jeweilige Telemetrie einbindet, und aus Anwendersicht. Ihr werdet sagen: Was interessiert mich Punkt 1? Doch ist das mMn ziemlich direkt mit Anwendungseffekten verbunden.
Das Spiel ist ja immer dasselbe: Der Empfänger hat eine digitale Schnittstelle für "freie Sensoren", einen Bus für selbige, am/im Sender hängt das Display.
Beide Verfahren benutzen einen 1-Wire-Bus, also Datenübertragung im Semiduplex.
[SIZE="3"]
JETI[/SIZE]
Pro:
Das Display is völlig offen, was da im Rahmen der Telemetrie erscheinen soll, bestimmt allein der jeweilige Sensor.
Das Display ist ein Terminal, sprich, es ist bidirektional (4 Cursortasten), das kann (bei JETI-eigenen Sensoren MUSS) man für beliebige Konfigurationszwecke benutzen. Ich ermögliche darüber z.B., dass JLog unter Umgehung der Konfigdatei CONFIG.txt via dieses Terminal (JETIbox) konfiguriert werden kann. Das könnte u.U. "im Felde" nützlich sein, man muss nicht unbedingt einen PC mitschleppen, um mittels "JLC" die Konfiguration (CONFIG.txt) zu ändern und via die SD dem Logger mitzuteilen.
Con:
Standardterminals sind bisher die große (erste) JETIbox oder JETIbox mini. Das sind jeweils nur zwei Zeilen á 16 Zeichen. Man muss sich schon bemühen, möglichst viele Sensordaten auf ein Display zu bekommen, wobei man im Wesentlichen auf die Maßeinheiten verzichten muss.
Das Protokoll ist "unsinnig" proprietär, 9 Datenbits plus Parity, wobei auch noch das neunte Datenbit "befummelt" werden muss.
Es wird mit 9600 Baud geklingelt, das kostet im Zusammenhang mit dem neunten Datenbit und dem 1-Wire Zeit, die der Prozzi eines Sensors u.U. nicht die Fülle hat.
Man muss immer ein ganzes Display senden, das sind inkl. Header/Trailer 34 Zeichen, - und das bei verträumten 9600 Baud...
Die JETIbox hat ein mMn unnötiges und zu kurzes Timeout implementiert, was zieht, wenn soundsolange keine Zeichen empfangen wurden. Nach ca. 170ms geht eine eingeschaltete Hintergrundbeleuchtung aus, nach 190..200ms wechselt das Display auf eine Timeout-Benachrichtigung.
Alles zusammen genommen, nur 9600Bd, Zwang zu 34 Zeichen pro ßbertragung, Timeout-Verhalten, kann zu Problemen mit dem Timing beim Sensor führen, - und das für die größte Nebensächlichkeit der Welt... Bei JLog2 führt das direkt zu verschärften Mindestanforderungen an die schreibende Zugriffsgeschwindigkeit der microSD.
[SIZE="3"]MPX[/SIZE]
Pro:
Ein klares, einfaches und effizientes Datenprotokoll kommt zur Anwendung, es sind weniger Zeichen zu übertragen und das bei "speedy" 38400 Baud.
Von dem Minidisplay des Senders Cockpit mal abgesehen (wie ich hörte, nur 8 Sensoren möglich (sonst 16), nur jeweils einer im Display), erlaubt das Display der ROYALpro 3 Sensorwerte je Seite, mit Hervorhebungen durch unterschiedliche Fonts (Zeichengröße) bzw. Inversdarstellung bei Alarm auf einem Sensorwert. Bei Alarm springt das Display um auf einen evtl. gerade nicht dargestellten Wert mit Alarm. (Das musste ich mit JETI umständlich barfuß machen.)
MPX's Sensorbus (Protokoll) arbeitet mit Sensorklassen, dadurch bekommt man auch jeweils die Maßeinheit hinten dran.
Con:
Es handelt sich nur um ein Display (im Sender), kein bidirektional (interaktiv) benutzbares Terminal.
Der Designer der Sensorklassen kommt mir vor wie die üblichen Architekten, die z.B. Kinderzimmer in Wäschekammergröße vorsehen...
Z.B. Maximalströme von 100A. Häh?! Zum Glück macht sich das Display im Sender auch nicht in's Hemd, wenn man ihm 250A anbietet. Schlimmer ist es mit der Drehzahl als Klassentyp, das geht grundsätzlich nur mit 100 UPM Auflösung, sprich, das Display multipliziert immer mit 100. Alles klar..., ich glaube aber nicht, dass es den Leuten schnuppe ist, ob der Rotor 1800 oder 1890 UPM dreht, Sprünge von 100 UPM sind dafür wenig hilfreich. Dagegen macht das bzgl. Drehzahlen von Motoren wahrscheinlcih den Kohl nicht fett.
Das zusätzliche akustische Melden von Alarmen ist mehr ein Witz, zu kurz, zu leise allemal (Piezo Buzzer im Sendergehäuse, kein extra Schallaustritt). Mit einem Wort: Akustische Alarme zum ßberhören.
In Summe würde ich der MPX M-Link Telemetrie trotzdem die bessere Note gegenüber JETI geben. JETI ist natürlich schön flexibel, fehlender Abstraktionsgrad bedingt nun mal mehr Detaillierung, und, je mehr Detail, je mehr Varianten in Anwendung, logisch. Trotzdem mutet das JETI-Protokoll wie der fehlgeschlagene Versuch einer Abschottung an, dabei ein gewisser "Bastlertouch".
Aber, nicht zu vergessen: Die Schlusslichter der Telemetrie sind diejenigen Systeme, die nur konventionelle Sensorschnittstellen (Spannung, Impulsfrequenz) bedienen können, also ausschließlich eigene Sensoren verarbeiten. Als Beispiel sei hier Spektrum genannt.
Ich betrachte es aus beiden Blickwinkeln, aus Sicht des Implementators, desjenigen, der Sensoren in die jeweilige Telemetrie einbindet, und aus Anwendersicht. Ihr werdet sagen: Was interessiert mich Punkt 1? Doch ist das mMn ziemlich direkt mit Anwendungseffekten verbunden.
Das Spiel ist ja immer dasselbe: Der Empfänger hat eine digitale Schnittstelle für "freie Sensoren", einen Bus für selbige, am/im Sender hängt das Display.
Beide Verfahren benutzen einen 1-Wire-Bus, also Datenübertragung im Semiduplex.
[SIZE="3"]
JETI[/SIZE]
Pro:
Das Display is völlig offen, was da im Rahmen der Telemetrie erscheinen soll, bestimmt allein der jeweilige Sensor.
Das Display ist ein Terminal, sprich, es ist bidirektional (4 Cursortasten), das kann (bei JETI-eigenen Sensoren MUSS) man für beliebige Konfigurationszwecke benutzen. Ich ermögliche darüber z.B., dass JLog unter Umgehung der Konfigdatei CONFIG.txt via dieses Terminal (JETIbox) konfiguriert werden kann. Das könnte u.U. "im Felde" nützlich sein, man muss nicht unbedingt einen PC mitschleppen, um mittels "JLC" die Konfiguration (CONFIG.txt) zu ändern und via die SD dem Logger mitzuteilen.
Con:
Standardterminals sind bisher die große (erste) JETIbox oder JETIbox mini. Das sind jeweils nur zwei Zeilen á 16 Zeichen. Man muss sich schon bemühen, möglichst viele Sensordaten auf ein Display zu bekommen, wobei man im Wesentlichen auf die Maßeinheiten verzichten muss.
Das Protokoll ist "unsinnig" proprietär, 9 Datenbits plus Parity, wobei auch noch das neunte Datenbit "befummelt" werden muss.
Es wird mit 9600 Baud geklingelt, das kostet im Zusammenhang mit dem neunten Datenbit und dem 1-Wire Zeit, die der Prozzi eines Sensors u.U. nicht die Fülle hat.
Man muss immer ein ganzes Display senden, das sind inkl. Header/Trailer 34 Zeichen, - und das bei verträumten 9600 Baud...
Die JETIbox hat ein mMn unnötiges und zu kurzes Timeout implementiert, was zieht, wenn soundsolange keine Zeichen empfangen wurden. Nach ca. 170ms geht eine eingeschaltete Hintergrundbeleuchtung aus, nach 190..200ms wechselt das Display auf eine Timeout-Benachrichtigung.
Alles zusammen genommen, nur 9600Bd, Zwang zu 34 Zeichen pro ßbertragung, Timeout-Verhalten, kann zu Problemen mit dem Timing beim Sensor führen, - und das für die größte Nebensächlichkeit der Welt... Bei JLog2 führt das direkt zu verschärften Mindestanforderungen an die schreibende Zugriffsgeschwindigkeit der microSD.
[SIZE="3"]MPX[/SIZE]
Pro:
Ein klares, einfaches und effizientes Datenprotokoll kommt zur Anwendung, es sind weniger Zeichen zu übertragen und das bei "speedy" 38400 Baud.
Von dem Minidisplay des Senders Cockpit mal abgesehen (wie ich hörte, nur 8 Sensoren möglich (sonst 16), nur jeweils einer im Display), erlaubt das Display der ROYALpro 3 Sensorwerte je Seite, mit Hervorhebungen durch unterschiedliche Fonts (Zeichengröße) bzw. Inversdarstellung bei Alarm auf einem Sensorwert. Bei Alarm springt das Display um auf einen evtl. gerade nicht dargestellten Wert mit Alarm. (Das musste ich mit JETI umständlich barfuß machen.)
MPX's Sensorbus (Protokoll) arbeitet mit Sensorklassen, dadurch bekommt man auch jeweils die Maßeinheit hinten dran.
Con:
Es handelt sich nur um ein Display (im Sender), kein bidirektional (interaktiv) benutzbares Terminal.
Der Designer der Sensorklassen kommt mir vor wie die üblichen Architekten, die z.B. Kinderzimmer in Wäschekammergröße vorsehen...
Z.B. Maximalströme von 100A. Häh?! Zum Glück macht sich das Display im Sender auch nicht in's Hemd, wenn man ihm 250A anbietet. Schlimmer ist es mit der Drehzahl als Klassentyp, das geht grundsätzlich nur mit 100 UPM Auflösung, sprich, das Display multipliziert immer mit 100. Alles klar..., ich glaube aber nicht, dass es den Leuten schnuppe ist, ob der Rotor 1800 oder 1890 UPM dreht, Sprünge von 100 UPM sind dafür wenig hilfreich. Dagegen macht das bzgl. Drehzahlen von Motoren wahrscheinlcih den Kohl nicht fett.Das zusätzliche akustische Melden von Alarmen ist mehr ein Witz, zu kurz, zu leise allemal (Piezo Buzzer im Sendergehäuse, kein extra Schallaustritt). Mit einem Wort: Akustische Alarme zum ßberhören.
In Summe würde ich der MPX M-Link Telemetrie trotzdem die bessere Note gegenüber JETI geben. JETI ist natürlich schön flexibel, fehlender Abstraktionsgrad bedingt nun mal mehr Detaillierung, und, je mehr Detail, je mehr Varianten in Anwendung, logisch. Trotzdem mutet das JETI-Protokoll wie der fehlgeschlagene Versuch einer Abschottung an, dabei ein gewisser "Bastlertouch".
Aber, nicht zu vergessen: Die Schlusslichter der Telemetrie sind diejenigen Systeme, die nur konventionelle Sensorschnittstellen (Spannung, Impulsfrequenz) bedienen können, also ausschließlich eigene Sensoren verarbeiten. Als Beispiel sei hier Spektrum genannt.
Kommentar