Schade, dass die Telemetrie meines Fernsteuersystems nicht unterschützt wird.
Das hört man öfter… Aber, warum ist das so?
Ein Telemetriesystem muss zwei Voraussetzungen erfüllen, damit es durch einen Fremdsensor wie JLog2 sinnvoll verwendbar ist:
Es muss einen “Bus” verwenden oder zumindest eine Schnittstelle für Fremdsensoren haben. “Bus”: Das ist entweder ein Sensorbus, wie z.B. der Multiplex-Sensor-Bus (MSB), oder es ist eine Terminalleitung wie bei JETI. Systeme, die in keiner Weise eine mehr oder weniger offene Schnittstelle anbieten, sind ungeeignet, um sich da mit JLog2 aufzuschalten. Diese Systeme haben ganz unterschiedliche Schnittstellen jeweils nur zu eigenen Sensoren. Wollte man hier die Daten eines Fremdsensors zur Übertragung und Anzeige hineinbringen, könnte man nur ganz außen an die Sensoren des Systems gehen, also eine Spannung oder eine Impulsfrequenz einspeisen, – für eine Spannung, einen Strom, eine Temperatur oder eine Drehzahl usw. seitens der Sensoren dieses proprietären Systems, stellvertretend für Daten, die man als Fremdsensor darstellen will.
Das war erstmal das Einspeisen von Daten zwecks Übertragung. Nun muss das aber noch identifizierbar im Display des Senders dargestellt werden. Ein System mit “Bus” oder “Common Interface” wird hier die Möglichkeiten bieten, die benötigt werden, um den Benutzer mit intuitiv lesbaren Daten zu versorgen:
• möglichst freie, erkennbare Zuordnung von Sensoren (Adressierung)
• Datenklassen: Wertebereich und Festkommaposition, Maßeinheit
Und genau das bietet ein Telemetriesystem ohne “Bus” oder “Common Sensor Interface” nicht!
Der Unterschied zwischen einem Sensorbus und der “Terminalleitung” von JETI:
Zunächst: JLog2 stellt (ebenso wie z.B. Unilog) einen “Multisensor” dar. Bei JLog steckt die Sensorik vornehmlich im JIVE, das ist die “Ur-Sensorik”, die eigentlichen Sensoren und ihre Messwerte bildet JLog. Optional werden auch eigene Sensoren verwendet. Ein “Multisensor” bildet i.Allg. auch “virtuelle Sensoren”, wie z.B. “Rotordrehzahl”, “mAh”, “Min-/Maxwerte”.
Beim “Sensorbus” muss sich nun der “Multisensor” für jeden seiner angesprochenen Sensoren so verhalten, wie es das Protokoll des Sensorbusses vorgibt, um seine Daten darstellungsrichtig an den Endpunkt, in’s Display des Senders, loszuwerden.
“Terminal” (JETIbox): Hier gibt es keinen Sensorbus. Stattdessen hat man ein Terminal, auch bidirektional verwendbar (hat 4 Cursortasten zur Eingabe), das via einen “Terminalbus” mit einem Sensor verbunden werden kann. Der gesamte Display-Inhalt wird eigenständig durch den jeweiligen Sensor gestaltet (2 Zeilen á 16 Zeichen mit der klassischen JETIbox und der JETIbox mini). Es gibt dann noch eine Bus-Option, den “Expander”, der ein geteiltes Display für das gleichzeitige Darstellen der Werte von zwei Sensoren ermöglicht, – es wird aber jeweils nur die zweite Zeile eines Sensor-Displays genommen.
Multisensoren wie JLog und Unilog bringen ihre Daten nun zwangläufig (weil nur 2 x 16 Zeichen) in mehrere Display-Seiten und benutzen das Terminal “JETIbox” interaktiv zur Seitenumschaltung. JLog2 liefert 23 Werte auf 5 Display-Seiten, plus eine Alarm-Popup-Seite. – Mit dem Sensorbus von Multiplex (MSB) sind max. 16 Sensoren möglich, wovon ein Sender max. 8 oder 15 in seinem Display zur Anzeige bringt. JLog2 liefert dann entsprechend auch nur max. 8 oder 15 Werte gleichzeitig.
Man kann also sagen: Die flexibelste Lösung ist der Terminalbus, ein Sensorbus ist aber ausreichend, sofern das Display am Ende flexibel genug bzgl. der Datendarstellung ist.
Für alles an Fernsteuersystemen, was so etwas nicht unterstützt und nur mit eigenen Sensoren arbeitet, die irgendwie und irgendwo angeschlossen sind, für um Zugang bittende Fremdsensoren völlig intransparent, gilt also unten stehendes Schildchen, - wobei dessen Inschrift für das Telemetriesystem wie für den Fremdsensor, hier JLog, im bilateralen Sinne zutrifft, leider:
Was vertretbar ginge, ist, das ansonsten ungeeignete Telemetriesystem wenigstens zur Alarmgabe zu benutzen. Man schließt eine Alarmleitung des Loggers z.B. an einen Temperatursensoreingang an, statt des Sensors, direkt oder via einen Spannungsteiler, und setzt stellvertretend im Sender oder Sensor einen Temperaturalarm. (vorausgesetzt, es handelt sich um einen analogen Sensor und nicht um einen digitalen auf einem 1-Draht-Bus) JLog2 unterstützt parallel zur Telemetrie bis zu zwei Alarmleitungen (Sammelalarm, und mAh-Alarm abtrennbar). Eine Alarmleitung ist low-aktiv, sie liefert nahe Null Volt bei Alarm und ca. 3,3V, wenn kein Alarm.
Werden weitere Systeme unterstützt werden? Ja, sofern sie obige Bedingungen erfüllen. HoTT steht unmittelbar vor Implementierungsbeginn, SBus2 wird sicher auch kommen, wenn er denn mal definiert ist. Die generelle Absicht ist, alle geeigneten Systeme bei Verfügbarkeit der jeweiligen Spezifikation zu integrieren. (Eine Eigenbaualternative mit moderatem Aufwand, weil nur Fertigmodule applizierend, XBee, spezielle JLog-Firmware, ist “JTX“.)
Es ist einfach schade, dass, beginnend mit 2,4GHz-Fernsteuersystemen, und mit deren Telemetrie jetzt massivst, jeder seine proprietäre Lösung anbietet, und, sofern es nicht wenigstens dabei einen Sensorbus oder eine andere Schnittstelle für Fremdsensoren gibt, somit jeweils seine eigene mehr oder weniger geschlossene Welt etabliert. “Kundenbindung” nennt man das wohl. Ob das nicht etwas kurz gedacht ist? JLog wird versuchen, auch zukünftig mit möglichst vielen Telemetriesystemen zu können. Durch die Menge von Daten, die der Logger live anzubieten hat, wird er es dabei oft nicht leicht haben.
———————————————————————————————————————————–
Das ist im Augenblick implementiert:
Dazu kommt, dass eine JETIbox oder ein Unidisplay oder eine Graupner Smart-Box (HoTT) auch direkt an den Logger angeschlossen werden kann, (teilweise) zum Konfigurieren mit jbJLC, ansonsten für Livedaten. Alternativ gibt es die “Telemetrie mit Eigenleistungen” JTX, basierend auf 2x Digi XBee (2,4GHz DSSS) und 2x JLog, jeweils mit spezieller Firmware (hier im Download).
