JETI v1 und EX

Achtung!  Anwender von Empfängern der JETI REX Serie müssen die jeweils neueste JLog Firmware (1. Juni 2015 oder später)  verwenden, für JLog 2.5 und 2 nur  ”konsolidierte” Firmware”!
Grund:  1) JETI spezifiziert zwar direkt 9600..9800 Baud, die REX Empfänger laufen aber nur mit knapp 9800 Baud, nicht darunter. JETI verwendet 9 Datenbits UND ein Paritätsbit, also 10 Bits neben Startbit und Stopbits. Die REX Empfänger enthalten einen 32Bit Microcontroller, der vermutlich nur max. 9 Bits INKLUSIVE Paritätsbit kann. JETI hätte sich damit selbst dazu gezwungen, einen Software-UART zu implementieren, – und dabei muss was bzgl. der Baudrate schief gegangen sein.  2) Text Mode: Ein REX enthält einen 3-Kanal-Expander (Multiplexer) in Software. Leider hält sich dessen Implementierung nicht an die Protokollspezifikation (von JETI :) ), was das Acknowledge Zeichen betrifft, das den Tastaturcode enthält.
Das Gute: JETI scheint diesen Expander nun endlich richtig gemacht zu haben. Er scheint nicht mehr dumm nach Zeit zu multiplexen, sondern nach EX Sensor und Message IDs. Endlich! Wurden wir etwa erhört? :)  – Das hieße dann: Wer mehrere Sensoren mit jeweils vielen Daten Displays betreibt und bisher Probleme hatte (JLog’s Data Config #3 verwenden musste), der sollte sich nun einen REX zulegen, wenn ihm 3 Expander-Eingänge ausreichen!
April 2016: Neue REX Firmware v1.02, neuer Bug um das ACK Byte (Tastenkode von einem Terminal im Text Mode): siehe. Der Sensor (JLog) empfängt Zombie Tastenkodes durch diesen Bug, navigiert dadurch eigenständig durch seine Displays. Es gibt dazu einen Workaround in Jlog, – er lindert gut, aber er kann nicht vollständig heilen. Bisher (8.4.) wurden die beiden JLog2.6 Firmwares für KOSMIK/Jpro erneuert, die anderen (17) für alle JLog folgen alsbald. ….Na ja.. :)  15.Juni 2016: Die nächste Firmware mit Bugfix für den REX1.02: ESC=(alter)JIVE
————————————————————————–
Gleich noch zwei Hinweise eingeschoben (steht eigentlich schon lange weiter unten), Anlass ist eine gegenwärtige Diskussion in RCH (Aug 2015):
1. Der rote Draht im Servokabel von JLog “COM” zum Tele-Port des Empfängers MUSS getrennt werden. Grund ist, dass sonst das Signal des 1-Wire-Anschlusses der Telemetrie auf Plus gelegt wird! Die Telemetrie funktioniert dann auf keinen Fall! ..außerdem könnte man etwas kaputt machen, Empfänger oder JLog.
2. Dass ein RSat in den Bindemodus gehen kann, hat einen einfachen Grund:  Der Signalpin am Tele-Port des Empfängers ist zu hochohmig. Wenn der RSat startet (Betriebsspannung bekommt), während JLog noch keine Spannung hat, dann ist JLog einfach nur ein Widerstand gegen Masse. Aufgrund der ungünstigen Dimensionierung am SigPin des RSat glaubt der nun, das wäre die Brücke gegen Masse, – und er geht in den Bindemodus. Gegenmaßnahmen:
 a) Wenn JLog nur aus dem Option Port eines KOSMIK/JIVEpro versorgt wird, der Empfänger aber aus einem externen BEC oder Akku (Puffer), dann muss das einfach passieren. Also bitte dafür sorgen, dass JLog zeitgleich mit oder vor dem Empfänger seine Betriebsspannung bekommt.
 b) Unpraktisch: Das Servokabel erst nach dem Power-up an COM stecken.
 c) Einen (Pullup-)Widerstand in’s Servokabel hinter dem Stecker empfängerseitig, ca. 10kOhm zwischen Signal und Plus.  Achtung! Bitte nicht den Pullup an “HV” BEC Spannung legen, das könnte zum Killer werden für die Microcontroller in JLog oder RSat! Dafür gibt es den <+> Pin an “JLog’s Port “S.Bus2/S.Port”. Hier kommen 3,3V raus, genau das Richtige für den Pullup.
Anschliessen
HoTT_Telemetry

Wichtig ist, dass der rote Draht getrennt wird!  Zerstörungsgefahr!

Der Telemetrieanschluss des Empfängers wird mit dem Port “COM” von JLog2.6/2.5 verbunden. Man verwendet dafür ein Servo-Patchkabel.
JETI verwendet einsog. 1-Wire-Interface (was keinen Sensorbus darstellt), es besteht nur aus “Masse” und “Signal”. Auf der Signalleitung wird simplex wechselseitig asynchron-seriell gesendet und empfangen, mit 9.600 Baud. Der rote Draht ist auch belegt, aber kein Bestandteil des Interfaces, hier liegt die R/C-Eingangsbetriebsspannung des Empfängers an, also auch “HV”, wenn der Empfänger “HV” betrieben wird.
JLog kann nicht via seinen COM Port mit Betriebsspannung versorgt werden. JLog2.6 und 2.5 haben auf dem mittleren Pin seriell Rx anliegen, am äußeren Signal-Pin seriell Tx. Das Zusammenschalten beider Pins, um einen 1-Wire-Bus zu bilden, erledigt die Firmware von JLog automatisch unter Zuhilfenahme eines speziellen Bauelements. Daher aber würde es die Kommunikation auf dem Telemetrieinterface stören, würde man hier Plus R/C-Spannung anlegen, den roten Draht nicht trennen. U.U. könnte eine HV-R/C-Spannung sogar den Microcontroller in JLog oder im Empfänger zerstören!  –  Dass seriell Rx und Tx in JLog nicht generell miteinander verbunden und nicht nur auf einem Pin herausgeführt sind, hat den Zweck, beide Anschlüsse auch getrennt verwenden zu können, wie es z.B. bei Nutzung von JLog’s “S.Bus2/S.Port” der Fall ist (Linked Port), bzw. für Anwendungen, die beide Prozessor-Pins extern benötigen, wie z.B. zum Betreiben eines Unidisplay, für JLog-eigene digitale Temperatursensoren mit HiTec Telemetrie oder mit einem Castle Creations ICE/EDGE und Telemetrie SPEKTRUM oder HiTec.
JLog2
Bei JLog2 sieht das etwas anders aus: Der Port “COM” ist eine Molex Buchse. Man braucht das Adapterkabel SM#2556. Es gibt aber auch die Möglichkeit, das Kabel kostengünstiger aus einem SM#2401 selbst zu bauen, ohne den Molex Stecker besorgen und crimpen zu müssen.
Seriell Rx und Tx vom COM Port von JLog2 müssen im Kabel miteinander verbunden werden und auf den Signal-Pin des JR-Steckers geführt werden, der in den Telemetrieanschluss des Empfängers geht. Das Adapterkabel SM#2556 tut das, ein Eigenbaukabel muss es auch tun, s.o.  Auch hier ist kein Platz für Plus R/C-Spannung vom Empfänger. Am roten Draht im Flachbandkabel an SM#2556 oder SM#2401 liegt eine Ausgangsspannung von JLog2 an, +3,3V, das ist die Ausgangsspannung des internen Spannungsreglers von JLog2. Der ursprüngliche Zweck dessen ist das Versorgen eines angeschlossenen Unidisplay, – aber auch andere JLog-Anwendungen verwenden die 3,3V. Es gibt zwar intern einen PTC (Kaltleiter) in der Masseleitung zum Schutz, aber zumindest das Anlegen von HV-R/C-Spannung könnte den Spannungsregler bzw. sogar den Microcontroller in JLog2 zerstören!JLog2-Molex
.
JLC
JETI EX
JETI (v1) war die erste R/C-Telemetrie am Markt, wenn ich mich richtig erinnere.
JETI EX ist das flexibelste Telemetriesystem derzeitig, zumindest für 3rd party Sensoranbieter, aber damit natürlich auch im Interesse der Anwender.
Allerdings auch: JETI EX krankt an seiner Historie, die mitgeschleppt wird, um abwärtskompatibel zu sein zu seinen Geräten, die man je verkaufte. Da kann man nur sagen: Hey, nicht so schüchtern! Nehmt Euch ein Beispiel an OpenTx/FrSky, die wechseln die Telemetriesysteme so schnell, dass nicht mal alle Händler und Kunden hinterher kommen. :)
Mehr dazu, sofern es JLog’s Anwendung tangiert, am Ende dieser Dokumentation.
.

JLog’s Daten in JETI Telemetrie

Text Mode
Abgesehen davon, dass ein Text von 32 Zeichen sowieso Bestandteil jeder Aussendung eines Sensors zu sein hat, verwendet JLog diesen auch, und zwar zur Ausgabe seiner Sensordaten. Für das Setup des Gerätes wird der Textmode nicht (mehr) verwendet. JLog hat einfach zuviel Parameter, als dass ein Setup mit alphanumerischen Displays von 2x 16 Zeichen produktiv wäre.
JLog sendet seine Daten in 5 Displays, Display #5 sind Min/Maxwerte der gegenwärtigen Boot Session. Sie setzen sich zurück durch Restart von JLog oder durch einen “Warmstart”, der ausgelöst wird, wenn JLog den Datenstrom des ESC verlor und dann wiedersieht (JLog läuft weiter, während der Antriebsakku gewechselt wird). Navigiert wird durch die Displays mit den Tasten –> und <–.
Im Falle eines Alarmzustandes popt ein sechstes Display hoch, das momentan alarmbehaftete Datenobjekte nebst ihrem Momentanwert anzeigt. Das Display verschwindet wieder, wenn kein Wert mehr mit Alarm behaftet ist, oder man quittiert den Alarm durch –> oder <–. Das Alarmdisplay verschwindet dann, und man ist wieder in dem Display, in dem man vor Eintreten eines Alarms war. Gleichzeitig stoppt JLog das Signalisieren der quittierten Alarme, als Popup im Textmode, als Alarmcode (Hidden Message), der z.B. in einem JETI EX Terminal (Profixbox, JETI Sender) zur Sprachausgabe führt, sofern der betreffende Alarmcode einem Voice File zugeordnet worden ist. Ein klassischer JETI Tx-Modul wird den Alarmcode morsen.  –  Verschwindet der Alarmzustand auf einen Wert, z.B. der auf Ubat, tritt aber später wieder ein, muss das erneut quittiert werden, wenn man will. Achtung bzgl. eines mAh-Alarms! Einmal quittiert, wird er nicht erneut signalisiert werden innerhalb dieser Boot Session (dieses Fluges)!
Die Screenshots stammen von JLog2.6. Seit JLog2.6, und zukünftig auch mit JLog2.5 und 2, signalisieren die Text Displays nicht mehr, wenn kein ESC-Datenstrom gesehen wird, wodurch der jeweilige Wert als “-.-” angezeigt wurde.
S1S2S3S4S5AA+
Die für die Screenshots verwendete textuelle JETIbox war eine Softwareemulation, Funktion einer Profibox. Da die Profibox gleichzeitig ein EX Terminal ist, gibt es eine Doppelreaktion im Falle eines Alarms:  JLog lässt den Textmode reagieren durch das Alarm-Popup-Display, gleichzeitig sendet er den zugehörigen Alarmcode in Form einer sog. “Hidden Message”, was zur Reaktion des EX Terminals der Profibox im Hintergrund führt.
.
EX Mode
JLog ist ein JETI EX Multisensor. Parallel zu einem textuellen Displayinhalt, den er mit jedem Datenpaket sendet, sendet er auch seine Sensordaten als sog. Hidden Messages v1.1, EX Messages, – nicht alle Sensordaten in einem Datenpaket, sondern verteilt über 3 Datenpakete, in Sonderkonfiguration in nur 2 Datenpaketen. Aus bestimmten Gründen sollte ein JETI EX Sensor wie JLog nicht mehr als 15 verschiedene Sensordaten senden. (Wen es interessiert, warum das so ist, der liest bitte den zweiten Abschnitt.) JLog hat aber, je nach seiner Konfiguration, mehr an diversen Sensordaten, als er damit in die Telemetrie loswerden kann. Deshalb gibt es insgesamt 4 Zusammenstellungen von JLog-Sensordaten, zwischen denen der Anwender im Setup von JLog per Konfigurator JLC wählen kann.
Die Wahl der Sensor-Zusammenstellung, als JETI Conf #0..3 bezeichnet, wird der User vor allem anhand von ihm verwendeter sog. JLog-eigener Sensoren fällen, Sensordaten, die nicht aus einem ESC stammen.
Jede Config enthält zunächst dieselbe Zusammenstellung namens “Base”, bestehend aus 9 Sensordaten, zzgl. weiterer 6 Daten, die je Config spezifisch sind. Config #3 enthält nur 3 spezifische Sensordaten in ihrem zweiten Teil. Dadurch ist es möglich, mit nur 2 Datenpaketen alle Daten als EX Messages auszusenden. Ein Verwenden von Config #3 könnte erforderlich werden, wenn JLog sich hinter einem JETI Expander E4 EX befindet, zusammen mit mehr als 2..3 anderen JETI(-kompatiblen) Sensoren, – und zwar dann, wenn man beobachtet, dass Displays im EX Terminal in’s Timeout fallen, “——-” zeigen.  (Zum Hintergrund dazu siehe den zweiten Abschnitt.)
Mit den Firmwares für JLog2.6 wurde der Cell Voltage Sensor CVS16 eingeführt, die Integration eines HV²BEC als JLog-eigener Komplexsensor vertieft, sowie weitere Veränderungen vorgenommen, was das Handling von JLog-eigenen Sensoren betrifft, in JLog und im Setup durch JLC. Außerdem wurde das Maximum unterstützter digitaler Temperatursensoren dabei von 5 auf 3 reduziert, der bisherige Spannungssensor 0..12,8V entfiel, dafür kann nun CVS verwendet werden.
Bitte beachten Sie, dass es im Verlaufe von Q2/2014 eine funktionelle Konsolidierung der Firmwares aller JLog-Typen geben wird. Dadurch werden dann o.g. Veränderungen und ihre Wirkung im Zusammenhang mit JETI Telemetrie auch für JLog2.5 und 2 zutreffen!
Um der dadurch nochmals gestiegenen Anzahl verschiedener Sensordaten in JLog auch in der JETI Telemetrie entsprechen zu können, gibt es nun zusätzlich eine automatische flexible Reaktion von JLog in der Sensordatenausgabe anhand seiner jeweiligen Konfiguration, was JLog-eigene Sensoren betrifft, “klassische” und sog. “Komplexe Sensoren” wie CVS16 und HV²BEC:
Ist ein CVS angeschlossen und konfiguriert, und befindet er sich im sog. automatischen Pack Mode (Cell Pack erkannt), dann liefert er die Total Pack Voltage. Diese ersetzt automatisch Ubat, was ja aus einem ESC kommt.
Ist ein HV²BEC an JLog angeschlossen und konfiguriert (JLC), dann werden Ibec und tFET, aus dem ESC stammend, ersetzt durch die Werte aus dem HV²BEC. (Natürlich wird auch dessen Verbrauch auf die Gesamt-mAh aufgeschlagen.).
Die Daten-Zusammenstellungen Config #0 und Config #3 verhalten sich in ihrem jeweiligen spezifischen Teil nun flexibel in der Auswahl und Darstellung von Sensordaten, und zwar abhängig davon, ob ein CVS16 oder/und ein HV²BEC im Setup von JLog konfiguriert wurden.
CVS16–JLog–>JETI EX:  Zusätzlich gibt es eine flexible Reaktion der Displays für den CVS16, und zwar in Abhängigkeit davon, ob er sich im Pack Mode befindet oder nicht. Wurde ein Cell Pack erkannt, z.B. ein LiPo Pack (Antriebsakku), dann erscheinen die Werte “LCV” (Lowest Cell Voltage) und “LCN” (Nummer der Zelle mit LCV) in EX Displays. Ist das nicht der Fall, dann wird CVS16 als einfacher Spannungssensor für bis zu 16 Spannungen 0..73,2V betrieben. “LCV” und “LCN” werden automatisch ersetzt durch “Volt Pin1″ und “Volt Pin2″, die Spannungen an den beiden ersten der 16 ins von CVS16, die zur Einzelspannungsmessung verwendet werden können.
Config #1 und #2 sind fix nach Anwahl (JLC), unabhängig davon, welche JLog-eigenen Sensoren in JLC aktiviert wurden. Config #3 reagiert neben seiner Anwahl als Konfigurationstyp zusätzlich darauf, ob CVS16 oder/und HV²BEC als Sensoren angeschlossen sind. Config #0 macht dasselbe wie #3, aber die CVS16-spezifischen beiden Displays reagieren zusätzlich auf den Modus, in dem sich CVS16 befindet, Zellenspannungssensor oder 16fach-Spannungssensor.
Zu beachten ist, dass sich die Datendarstellung (Kommastellung) im JETI EX Terminals (Profibox oder JETI Sender) zwar sofort ändert, wenn JLog Displays dynamisch umkonfigurierte, es dauert aber etwas, bis zu 10 Sekunden und u.U. länger (Expander-Nutzung), bis sich die textuelle Darstellung der Displays auch ändert. Das liegt in der Natur des Protokolls, nach der ein Sensor (JLog) textuelle Display Definitionen relativ selten sendet, um Leitungskapazität zu schonen. Zumindest mit einer Profibox ist es erforderlich, die Seite á 4 Displays zu wechseln, bevor sie  textuelle Updates auf einer Seite auch anzeigt, also geänderte Namen und Dateneinheiten.
Config #0..3 (JLC)
C0C1C2C3
.
Alarmcodes
…, die JLog verwendet: .. In JETI v1 (nur “Simple Text”) generieren und senden nur Sensoren Alarme, das sind Buchstaben ‘A’..’Z’. In JETI EX kann ein Terminal, Sender oder Profibox, auch selbst Alarme generieren, und zwar auf die empfangenen binären Daten (“Parameter”) in EX Messages. Parallel können EX Terminals aber auch Alarme der Sensoren auswerten. Man kann die Sensoralarme (Buchstaben) vorhandenen Voice Files für die Sprachausgabe zuordnen (Mapping). Im Gegensatz zu HoTT, z.B., wird dann auch der aktuelle Wert gesprochen, wenn der Alarm meldende Sensor parallel EX Messages sendet.
JLog verwendet folgende Alarmcodes:
  • U ….. Alarm auf Ubat (inkl. UC, OOB, OOIRD Alarm vom CVS16 und LCV Alarm CVS16/JLog)
  • C ….. mAh Alarm
  • T ….. Alarm auf tFET (ESC Endstufen)
  • M …..Ubec Dip Alarm
  • V ….. Underspeed (Stall Speed)
  • B ….. Overspeed
  • N ….. Übertemperatur auf einem der bis zu 3(5) JLog-eigenen Temperatursensoren
  • E ….. Übertemperatur externer BEC (HV²BEC)
.
Terminal
Bitte nicht vergessen, dass das Terminal die “Parameter” (Daten, Displays) eines Sensors (hier JLog) erst lernen muss. In der Profibox geht das Parameter für Parameter quasi manuell, in einem JETI Sender muss man einen Scan ausführen lassen. Zu einem möglichen Problem dabei, betrifft Parameter #1, Ubat,  im zweiten Teil.
Hier ab 14:20Min wird es an einer DS-16 gezeigt. (Achtung! Laaangatmig, dafür teilweise Falsches.. Die Höhe kommt mitnichten aus dem GPS.) Offenbar hat sich etwas an der Senderfirmware geändert. Kein einmaliger Scan mehr, wie ich es an der DC-16 kennenlernte, stattdessen “Dauer-Scan”, – die Sensoren senden ja ständig ihre textuellen Display-Definitionen. Nach dem Einschalten muss man dem Ganzen etwas Zeit geben, die Definitionen werden ja relativ selten gesendet.
Im Deutschen Manual von JETI (DC-16, DS-16, DS-14) ab Seite 120.
.
So schaut es dann live aus:
Allgemeiner Teil (“Base”, 9 Displays), Bestandteil jeder Config, –  Displays 1..8
D1-4D5-8
.
Spezifische Displays
Config #0  -  kein HV²BEC, kein CVS16
D9-12D13-15
.
Config #0  -  HV²BEC, kein CVS16
D9-12D13-15
.
Config #0  -  kein HV²BEC, CVS16
………. CVS16 im Pack Mode
D9-12-pack
………. CVS16 nicht im Pack Mode
D9-12-nopack
.
………. weitere Sensordaten
D13-15
.
Config #0  -  HV²BEC + CVS16
………. CVS16 im Pack Mode
D9-12-pack
………. CVS16 nicht im Pack Mode
D9-12-nopack
.
………. weitere Sensordaten
D13-15
.
Config #1
D9-12D13-15
.
Config #2
D9-12D13-15
.
Config #3  -  kein HV²BEC, kein CVS16
D9-12
Config #3  -  HV²BEC, kein CVS16
D9-12
Config #3  -  kein HV²BEC, CVS16
D9-12
Config #3  -  HV²BEC + CVS16
D9-12.
Config #0 mit CVS16:  Wenn man alle Balancerstecker der Akkupacks von CVS16 abzieht, fällt CVS ergo aus dem Pack Mode. JLog ändert daraufhin zwei Displays inhaltlich und namentlich, “LCV”–>”Volt Pin1″, “LCN”–>”Volt Pin2″. Wenn JLog an CVS16 Motorstromfluss signalisiert, verharrt CVS16 in dem Mode, den er vorher durch Erkennen oder Nichterkennen eines Packs einnahm. Das ist erforderlich, um im Falle eines Totalverlusts eines Akkupacks nicht gleich aus dem Pack Mode zu fallen, schließlich sind Alarmbedingungen daran geknüpft.  –  Außerdem ist es so, dass, wenn CVS16 im Pack Mode “verriegelt”, weil JLog Stromfluss signalisiert, sich dessen Monitoring Rate nochmals erhöht, wenn weniger als 16S angeschlossen sind. Das ist zwar nicht wirklich erforderlich, ist aber “schick” aus Sicht des Entwicklers. :)
Config #1 und #2 sind gewissermaßen “Themen-Configs”, zumindest macht #2 wenig Sinn, wenn man weder CVS16 noch HV²BEC betreibt.
Jeder JETI Sensor, wie JLog, hat eine sog. “Equipment ID”. Aufgrund eines JETI Bugs, der im zweiten Abschnitt beschrieben ist, ist es erforderlich, dass JLog für Config #3 eine andere ID verwendet als für Config #0..2. Wechselt man die Konfiguration zwischen 0..2 und 3, oder umgekehrt, muss JLog daher komplett erneut im EX Terminal angelernt werden!
.
JETI Empfänger und extra R/C Stromversorgung
Der Empfänger geht in den Bind Modus, wenn er bei seinem Powerup LOW am Signalpin seines Telemetrie-Ports liest. Er ist ungewöhnlich “empfindlich” bzgl. dessen, LOW ist bereits eine hochohmige Verbindung gegen Masse. Hat man nun ein Setup, in dem JLog seine Betriebsspannung NACH dem Empfänger bekommt (z.B. Rx aus einem Empfängerakku oder Puffer und JLog aus dem BEC des ESC), dann kann es dazu kommen, dass der Rx in den Bindemodus geht. Grund ist, dass eine spannungslose Elektronik (hier die des JLog) gewissermaßen ein nichtlinearer Widerstand ist, unvorhersehbarer Natur, ein Widerstand gegen Masse. Genau das glaubt der Empfänger dann, zu sehen, und zwar so, dass er es als Bind Jumper interpretiert.  –  Abhilfe schafft hier, JLog aus derselben Spannungsquelle zu versorgen, parallel zu seiner (späteren) Versorgung aus dem BEC des ESC oder einem anderen BEC. Siehe dazu Anschlüsse und Stromversorgung. Wie dort nachzulesen: JLog schafft dadurch KEINE Brücke zwischen beiden Spannungsquellen. Ziel ist, JLog’s Elektronik durch anliegende Betriebsspannung in einen definierten Zustand zu bringen, damit dessen Telemetrieausgang hinreichend hochohmig ist, bevor der Rx die Leitung hinsichtlich “Bind ja/nein?) auswertet.
.
Voice
Das Terminal (Sender, Profibox) mappt Parameternamen (Displaynamen) und Units (Maßeinheiten) auf Voice Dateien, – außerdem Alarme (‘A’..’Z'). JLog verwendet teilweise Parameternamen, für die es kein Mapping gibt, z.B. nennt er einen Parameter “mAh” statt “Kapazität” bzw. “Capacity”. Dem kann man das Mapping anpassen. Mancher will auch einfach eigene, andere Ansagen.
Hier steht, wie man das Mapping verändern kann.
.
Allgemeine Setup-Beschreibung, siehe auch:
Mark Kovalcson:  Setting up JLog2 Telemetry to the Jeti DS-16
Mark Kovalcson:  Configuring JLog 2.5 with Kosmik and Jeti
.
—————————————————————————————————————————————————————
Der folgende Abschnitt ist nur die “Kür”. Man sollte ihn nur lesen, wenn man Interesse hat. Zunächst wird JETI Telemetrie etwas tiefergehender erklärt als Grundlage für drei Teilabschnitte am Ende: 1) Warum gibt es nur Daten-Kompilationen und keine freie Wahl für den Anwender, welche Daten er JLog in die Telemetrie senden lassen will? Warum gibt es die Daten-Kompilation “Conf #3″? .. 2) Warum wird “Conf #3″ unter anderer “Equipment ID” für JLog gesendet als “Conf #0..2″? Erläuterung eines JETI Bugs. .. 3) JETI Bug, der dazu führen kann, dass das erste Sensor Display beim “AUTO” häufig nicht durch einen JETI Sender gelernt wird.
Lesen auf eigene Gefahr. :)
“Effekte”…….JETI Telemetrie verstehen
Dazu muss auch hier das in “Dokumentation” propagierte Prinzip gebrochen werden, Fremdkomponenten nicht dokumentieren zu wollen. :)
Im Gegensatz zu allen anderen Telemetriesystemen verwendet JETI keinen Sensorbus. Es gibt keine Arbitration, keinen Mechanismus (Protokoll) und keine Instanz (Busmaster), was die Kommunikation koordiniert. Alles, was es gibt, ist eine Leitung, die zwei Endpunkte verbindet, auf der einen Seite EIN Sensor, auf der anderen ein Datenterminal, JETIbox oder Sender. Es ist sogar noch “primitiver”, – die beiden Endpunkte bauen nicht bewusst eine Verbindung miteinander auf. Stattdessen sendet der Sensor einfach ungefragt ständig seine Datenpakete, ca. alle 100ms eines, und es ist ihm vollkommen egal, ob ihm jemand zuhört. Ein Sensor betrachtet somit die Leitung, an die er angeschlossen ist, grundsätzlich als privat.
Um nun den Rest zu verstehen, muss man wissen, dass jedes Datenpaket eines Sensors zwei Typen Messages enthalten kann, und dass die Datenwege beider Message Typen unterschiedlichen Methoden der Übermittlung zum Terminal unterliegen:
  • “Simple Text”, 32 Zeichen für ein Display von 2x 16 Zeichen
  • “Higher-Layer Protocol” == “Hidden Message”
Simple Text (Text Messages)
Betrachten wie zunächst die “Leitung”:  Sensor –> 1-Wire(simplex)/asynchron-seriell,9600Baud –> Empfänger als Tx/Rx –> HF-Strecke –> Transmitter als Rx/Tx –> Terminal.  Hier erst mal nur erwähnt: Zwischen Sensor und 1-Wire kann ein JETI “Expander” sitzen. Der Expander konnektiert den 1-Wire, bis zu 4 Sensoren konnektieren die Rückseite des Expanders.  –  Die aktiven Instanzen der Leitung, Expander, Empfänger und Transmitter, fungieren als Repeater. Parallel stellt aber auch jede dieser Instanzen selbst einen  ”Sensor” dar, die Leitung kann in der Instanz enden, statt weiterverbunden zu werden.
Leitung
JETI Messages haben keinen Adressaten, sie enthalten keine Information über einen Empfänger der Message in Bezug auf die Leitung oder das Kommunikationsprotokoll. Um eine Text Message in’s Terminal zu bekommen, muss das Terminal somit mit der sendenden Instanz durchverbunden sein auf der teilweise virtuellen “Leitung”. Das geschieht durch Interaktion zwischen einem Terminal, aber nur in der Form einer JETIbox, mit den Instanzen der “Leitung”, die als Repeater und primitive Vermittler fungieren, sozusagen elektronische Schalter zwischen ihren Ports zur “Leitung”. “Interaktion” ist das Bedienen der Instanzen mittels JETIbox durch den Benutzer:  Hat die JETIbox eine Text Message empfangen, quittiert sie das. Die Quittung enthält den Tastencode, den Status ihrer 4 Tasten. Dem Sender einer Text Message ist es zwar egal, ob jemand quittiert, erfolgt das aber, kann er mit den 4 Tastenstati etwas anfangen im Sinne von Interaktivität. Somit kann der Benutzer Funktionen einer Instanz der Leitung steuern, er kann ihr in ihrer Funktion als Repeater z.B. sagen, dass er zur nächsten Instanz der Leitung weiterbunden werden will. Am Ende der Durchvermittlung, gesteuert durch den Benutzer, landet man beim Sensor. Die JETIbox empfängt nun dessen Text Messages, quittiert ihm mit ihrem Tastenstatus, und der Benutzer ist interaktiv mit dem Sensor.  –  Interaktivität wird genutzt, um durch verschiedene Displays des Sensor zu navigieren, sofern er das anbietet. Man kann aber auch den Sensor darüber konfigurieren (Setup). Das ist der Vorteil so eines Textmodes: Der Sensor ist im Rahmen des Zeichensatzes und des Displayaufbaus (2x 16Z) völlig frei in der Gestaltung seiner Datendarstellung, und durch diese Freiheit kann er auch sein Setup anbieten. Nachteilig an dieser Freiheit ist zumindest, dass ein Terminal keinen Fixpunkt zur “maschinellen Interpretation” der in den Displays enthaltenen Daten hat, für Sprachausgabe von Datenwerten. Jedenfalls wäre das Terminal abhängig von eventuellen Änderungen der Software im Sensor, die den Aufbau seiner Displays ändern. Ein weiterer Nachteil ist der Overhead an Daten in der Textform. HoTT als einzige weitere Telemetrie, die Text Messages kennt, betreibt den Textmode daher exklusiv zum binären Mode, hier sind es 8x 21 Zeichen je Text Display.
“Leitung” again
Eine Instanz der “Leitung” muss nicht als Repeater verwenden werden, man kann auch in ihr enden, mittels JETIbox diese Instanz als Sensor verwenden (Transmitter und Empfänger bieten das) oder sie einem Setup unterziehen.
Nochmals zurück zur “Leitung”. Instanz “Transmitter”:  In der Vergangenheit war das ausschließlich ein JETI Tx-Modul, den man in einen Fremdsender einbaute. Heute ist es auch eine JETI Profibox, sofern als “Tx-Modul” an einem Fremdsender verwendet (PPM-Verbindung Sender–Profibox), oder der Transceiver in einem JETI Sender.  –  Um noch mal die Begrifflichkeit zu klären:  Wenn wir “Tx” oder “Rx” sagen, sprechen wir eigentlich jeweils von Transceivern (“Sendeempfängern”), beide können senden und empfangen. Nur ist eben die Hauptübertragungsrichtung unterschiedlich zwischen der Übertragung von Fernsteuersignalen im Vergleich zu der von Sensordaten usw.  Für manchen Anwender wird das verwirrend bzgl. einer Pofibox:  Verwende ich die Box als “Tx-Modul” in PPM-Ankopplung an einen Fremdsender, dann ist die HF-Kommunikation bidirektional. Die Profibox als JETIbox im Sinne des Textmodes kann dann verwendet werden, um die Instanzen der “Leitung”, Empfänger, Expander, Sensor, interaktiv zu “bedienen”, der Tastenstatus der Profibox wird denen zugesendet. Ich kann die Profibox aber auch als reinen Empfänger der Teletriedaten eines JETI Empfängers betreiben. Das ist dann one-way, die Profibox enpfängt alle Daten, kann aber nicht ihren Tastenstatus senden, kann nicht quittieren. Das ist für “EX” Datendisplays adäquat, aber als JETIbox im Sinne des Textmodes ist die Profibox dann “hilflos”, ihr Benutzer kann nicht navigieren. Text Messages von Sensoren beobachten zu wollen, ist in diesem Betriebsfall ziemlich sinnlos, weil man ja mit einer anderen JETIbox, z.B. am “JETI Tx-Modul”, dem man außerdem an einem Fremdsender betreibt, zum gewünschten Sensor und “in ihm” zum gewünschten Textdisplay des Sensors navigieren müsste. Das ginge auch alternativ mit der Profibox, indem man sie vor dem Starten kurz statt des Empfängers auf die Leitung hängt. Das wäre aber alles nur Krampf, natürlich.
Higher-Layer Protocol – Hidden Messages
Hidden Messages werden immer durch alle Instanzen der “Leitung” durchvermittelt, unabhängig vom virtuellen Verbindungsstatus für Text Messages. Wer von den Instanzen etwas damit anfangen kann, interpretiert es. Eine Hidden Message kann zusätzlich zur Text Message in einem Datenpaket enthalten sein, muss das aber nicht.
Vor “EX” gab es nur einen Typ Hidden Message, heute “v1.0″ genannt und immer noch in Verwendung. Enthalten ist ein Alarmcode in Form eines Buchstaben ‘A’..’Z’ (differenzierte Alarme). Vor “EX” nahm den nur ein klassischer JETI Tx-Modul und gab ihn als Morsezeichen akustisch aus per Piezo Buzzer. Im Gegensatz zur HoTT SmartBox hat eine klassische JETIbox keinen Buzzer.  –  Ein weiterer Typ Hidden Message, heute von JETI namentlich lieber nur unter “Higher-Layer Protocol” subsummiert, ist eine sog. “Expander Navigation Sequence”. Die gab es bereits in “v1″, die gibt es auch in “EX”. Es ist an dieser Stelle nicht von Bedeutung, sie zu verstehen, – man überlege sich nur einmal, wie man denn im Textmode per JETibox durch die Instanzen navigieren will, ohne eine Tasten-Sequenz zu haben, die eine Rückkehr in die Instanz davor erlaubt. ;)
Protocol
“EX” Hidden Messages
Mit “EX” wurde ein weiterer Typ Hidden Message eingeführt, “v1.1″. Im Grunde genommen basiert “EX” nur noch auf diesen Hidden Messages, ein “EX” Sensor sendet in jedem Datenpaket so eine Message, wenn er nicht mal eine Hidden Message v1.0 oder eine “Expander Navigation Sequence” sendet. Die Text Message (“Simple Text”) ist aber weiterhin in jedem Datenpaket enthalten, kann zur Datenanzeige verwendet werden, dient aber meist nur noch dem Setup des Sensors. Ein Alarmstatus des Sensors wird weiterhin als Hidden Message v1.0 gesendet, nur kann ein “EX” Terminal darauf nun einen Voice File mappen, eine Profibox oder ein JETI Sender kann das, Sprachausgabe differenzierter Alarme von Sensoren. Empfängt das “EX” Terminal dabei auch binäre “EX” Sensordaten, wird im Alarmfalle auch der aktuelle Wert gesprochen, – HoTT kann das z.B. nicht.
Hidden Messages v1.1 erreichen ebenso jede Instanz der “Leitung”, werden immer durchvermittelt. Letzendlich sind sie aber nur durch “EX” Terminals interpretierbar, Profibox oder JETI Sender.
“Hidden Message v1.1″ kann von unterschiedlichem Subtyp sein: Relativ selten sendet ein “EX” Sensor die Definition der textuellen Darstellung von Daten-Displays, Name und Einheit und dazu eine ID, z.B. “Strom” und “A”, ID 3. Auch der Name des Sensors selbst wird dabei gesendet, z.B. “JLog”, JETI nennt das “Equipment”.
Wesentlich häufiger wird der binäre Subtyp gesendet, er enthält die eigentlichen Sensordaten. Der Sensor übermittelt jeweils den binären Datentyp aus einer Auswahl, die das Protokoll definiert, die Kommastellung und den Wert selbst. Eine Hidden Message v1.1 (also eine “EX” Message) des binären Subtyps kann mehrere Sensor-Datenwerte enthalten, limitierender Faktor ist nur die maximal zulässige Größe der Message. Wieviele verschiedene Daten in eine Message hineinpassen, – und damit in ein Datenpaket eines Sensors, alle 100ms gesendet, – ist also eine Frage des Platzbedarfs des binären Datentyps, der genommen werden muss.
Die beiden “EX” Message Subtypen nennt JETI “text” und “data”. Text Messages werden so selten wie möglich gesendet, um die Leitungskapazität zu schonen, für Daten. Es geht ja nur darum, dass das Terminal einmal Namen und Dateneinheit je Display lernt, im Rahmen des initialen Einrichtens (“AUTO” (Scan) im JETI Sender), oder wenn sich das änderte seitens des sendenden Sensors.
Jede “EX” Message führt eine ID mit, den Adressaten, das Datendisplay des Sensors, sowohl jede Text Message als auch jede Data Message. Darüber kann dann das Terminal zuordnen, Daten zu einem textuell definierten Datendisplay, Name und Dateneinheit. Im Standard sind das die IDs 1..15 in Data Messages, entsprechend 1..15 in Text Messages, ID Null einer Text Message adressiert den Sensornamen, “Equiment Name”, “JLog”, z.B.
Das “EX” Protokoll wurde ja durch JETI offengelegt. Das war schon ganz witzig: Mit Einführung von “EX” 2011 versuchte JETI zunächst alles, das Protokoll geheim zu halten. Man verschlüsselte sogar die Daten. Als der erste JETI Sender erschien, gab es einen Sinneswandel. Die Verschlüsselung verschwand, das Protokoll wurde sogar offengelegt. Die meisten Implementatoren von Sensoren für JETI “EX” gehen davon aus, dass ein Sensor maximal 15 Datendisplays beschicken kann. Tatsächlich ist das aber nicht so, es sind bis zu 256 bzw. 255 theoretisch möglich, nur ist das in der Protokollbeschreibung nicht komplett ausgeführt. Allerdings gibt es genügend Gründe, sich als Sensor auf maximal 15 Werte zu beschränken, nicht nur das Limit im Terminal hinsichtlich der max. Anzahl definierbarer Displays:  Je mehr Werte ich als Sensor übermittle, um so mehr  aufeinanderfolgende Datenpakete benötige ich, um alle Werte als “EX” Messages verpackt auszusenden. An der Stelle kommt aber vor allem ein evtl. eingesetzter Expander in’s Spiel, und damit sind wir bei den “Effekten”.
Da wir eh schon so ausführlich sind, sei hier noch die “Display Konzentrator” Funktion des Expanders erwähnt, die auch bereits die Nicht-EX-Variante des Expanders hatte:  Im Navigation Menu des Expanders sieht man die ersten Zeichen der zweiten Zeile jedes aktiven Sensors hinter dem Expander. Man kann jeweils ein Pärchen von Sensoren auwählen, von dem jeweils die zweite Zeile in’s Display gelangt, Zeile 2 von Sensor 1 in Zeile 1, Zeile 2 von Sensor 2 in Zeile 2.  –  Eine Möglichkeit vor oder ohne “EX”, auch Daten von mehr als einem physischen Sensor (“Equipment”) in einem Display haben zu können.
“Effekte”
Nun ja, “Effekte” ist eine nette Umschreibung für “Bugs”, erwähnenswert, sofern es JLog tangiert. Leider ist auch erwähnenwert, wie lange diese Bugs bereits existieren, somit von JETI ignoriert werden. Erwähnt werden, müssen 3 solcher “Effekte”:
Design Bug um JETI Expander E4 “EX” ……. Expander in JETI Empfängern der Serie “REX” ist OK!
So ein Expander ist ja die letzte mögliche Zwischeninstanz auf dem Wege durch die “Leitung”, um ein Terminal (JETIbox bzw. emulierte JETIbox in einem JETI Sender) an die Text Messages eines Sensors zu bringen. Hidden Messages, Alarme (v1.0) und “EX” werden unabhängig vom textuellen Verbindungsstatus durch den Expander hindurch vermittelt.
Der Expander hat einen Port zum 1-Wire, 9600 Baud, der ihn mit dem Empfänger verbindet, und 4 Ports, 1-Wire, 9600 Baud, “hinter sich”, an die Sensoren angeschlossen werden können, v1 oder “EX”. Damit ist schon mal klar, dass sich die Leitungskapazität viertelt bei 4 Sensoren am Expander, die Latenz der Daten jedes Sensors vervierfacht sich. Ein Sensor sendet bis zu 63 Zeichen pro Datenpaket, 32+2 Zeichen Text, max. 29 Zeichen Hidden Message v1.1 (“EX”), oder alternativ zu “EX” Hidden Message v1.0 (Alarm) oder eine “Expander Navigation Sequence”. Beide Alternativen zu einer “EX” Message sind aber deutlich kürzer als diese. Ein Zeichen sind 1 Startbit, 9 Datenbits, 1 Paritybit, 2 Stopbits ==13 Bits/Z.  Das Aussenden eines Pakets braucht somit  85,3ms plus evtl. Gaps zwischen den strukturellen Items eines Datenpakets. Nach dem Aussenden geht der Sensor für 20ms auf Empfang für eine evtl. gesendete Quittung durch die JETIbox (Tastenstatus). Die 100ms sind also voll, und 100ms nach dem Start eines Datenpakets folgt bereits sein nächstes. Es gibt also keine Leitungsreserven für einen weiteren Sensor, ein Expander teilt einfach alles durch die Anzahl der Sensoren hinter ihm.
Nun ja, eine Latenz von 400ms bei 4 Sensoren wäre ja nun wirklich nicht so schlimm. Allerdings reden wir auch von Daten, die als “EX” Messages übertragen werden, und die brauchen nun mal bei vielen Sensoren mehr als ein Datenpaket des Sensors. Benötigt der Sensor 2 Datenpakete, um alle Sensordaten per “EX” auszusenden, wäre die Latenz bei 4 Sensoren schon 800ms, bei 3 Paketen 1,2s.  –  Über Latenz zu diskutieren, hat letztendlich nur akademischen Wert, zumal im Alarming, darauf basierend, noch evtl. wesentlich höhere Latenzen durch den nur sequentiell nutzbaren Voice Module hinzu kommen, wobei die Länge der Voice Message eine Rolle spielt.
Wesentlicher ist aber leider, dass die “EX” Datendisplays im Terminal, Profibox oder JETI Sender, durch einen zwischengeschalteten Expander in’s Timeout fallen können, nur noch Striche “——-” zeigend.  Das ist der Punkt, an dem von “Design Bug” zu sprechen ist, und zwar in Bezug auf einen Expander, durch den Sensoren “EX” Messages senden. Man fragt sich, was an der Bezeichnung “Expander E4 EX” nun “EX” ist. Jedenfalls agiert die Firmware des Expanders nicht sensitiv auf die unterschiedlichen “EX” Data Messages der Sensoren hinter ihm, obwohl sie das leicht könnte. Schließlich hat jeder Sensor (“Equipment”) eine ID, und jede “EX” Data Message eines Sensors hat auch eine ID zwecks Zuordnung zum textuell definierten Datendisplay, “Strom”, “A”, z.B. Der Expander sollte diese Messages intelligent puffern, und, über alle hinter ihm sendenden Sensoren, in einer Reihenfolge auf die Leitung zum Empfänger geben, dass garantiert ist, dass alle “EX” Datendisplays im Terminal innerhalb einer bestimmbaren Zeit ein Update erhalten. Somit könnten die Displays nicht in’s Timeout fallen. Stattdessen aber macht auch der Expander E4 “EX” ein nichtsensitives Round Robin, schaltet einfach nur im Zeittakt jeweils einen Sensor auf die Leitung. Da die Aussendungen der Sensoren untereinander und mit dem Expander nicht koordiniert sind, gibt es immer die Chance, bestimmte “EX” Data Messages zu oft zu verpassen, nicht auf die Leitung zu geben, wodurch sie zu selten oder gar fast nie das Terminal erreichen. Je mehr Datenpakete ein Sensor benötigt, um einen kompletten Satz seiner Sensordaten per “EX” Data Messages auszusenden, je mehr Sensoren sich hinter dem Expander befinden, die mehrere Datenpakete dafür benötigen, desto größer ist die Chance für Datenverlust bzw. extreme Latenzen, und damit für Timeout Effekte.
Da das nur durch JETI heilbar wäre, indem man die Firmware des Expanders verbessert, meintwegen auch “mit dem Holzhammer”, indem man die Baudrate wesentlich erhöht, muss sich ein Sensor wie JLog darauf einstellen. Daraus folgt:
JLog verzichtet auf das “Enhanced Addressing”, sendet nur max. 15 Datenwerte
JLog selektiert von ihm gesendete Daten nach dem Prinzip höchster Packungsdichte, sodass er mit möglichst wenigen Datenpaketen auskommt, um alle seine Daten als “EX” Data Messages loszuwerden. Damit ist ausgeschlossen, dass ein JLog Anwender selbst wählen kann, welche Daten er als JETI Sensor “JLog” sendet. Stattdessen bietet JLog per JLC drei vordefinierte Daten-Kompositionen an, zwischen denen der Anwender im Setup per JLC wählen kann. Dadurch ist garantiert, dass JLog stets nur 3 Datenpakete benötigt, um alle seine Sensordaten per “EX” Data Messages auszusenden.
Für den Fall, dass sich JLog zusammen mehr als 2..3 Sensoren hinter einem Expander befindet, und wenn sich dadurch sporadische Timeout Effekte in JLog’s Datendisplays im Terminal zeigen sollten, bietet JLog eine spezielle (vierte) Daten-Komposition an, die benötigte Datenpakete für ein komplettes Aussenden aller “EX” Data Messages von 3 auf 2 reduziert. Damit ist es gemäß Tests möglich, in jeder Konstellation hinter einem Expander mit anderen Sensoren “ungeschoren” koexistieren zu können.
Bug #1
Jeder Sensor, im Sinne von JETI als “Equipment” zu bezeichnen, hat eine eindeutige ID. Das Terminal lernt die Datendisplays und den “Equipment Name” in Relation zu dieser ID. Interessanterweise scheinen sowohl Profibox als auch JETI Sender die Eigenart zu haben, eine einmal gelernte Display-Struktur nicht wieder hergeben zu wollen, egal, ob man den Sensor (“Equipment”) explizit löscht vor neuem Einlernen (“AUTO” beim JETI Sender). Ändert sich die textuelle Repräsentation eines Datendisplays per “EX” Text Message, ID 1..15 (andere ID als die Equipment ID!), dann honoriert das das Terminal sehr wohl, Name und Dateneinheit ändern sich entsprechend. Wenn aber der Sensor (“Equipment”) sein Verhalten änderte, indem er bestimmte Datendisplay-IDs nicht mehr beschickt, dann beharrt das Terminal darauf, die Display-IDs auch darzustellen, im Timeout Status natürlich, und das nur, weil es irgendwann mal sah, dass diese “Equipment” ID (JLog) auch diese Display-IDs bedachte. Wie gesagt, trotz vorangegangener Komplettlöschung.
JLog entspricht dem, indem er die wegen des Expander Bugs reduzierte Daten-Komposition (Conf #3), 12 statt sonst 15 Datendisplays, unter einer anderen “Equipment” ID für JLog sendet, als die anderen 3 wählbaren Daten-Kompositionen (Conf #0..2).  –  Unbequemer Side Effect davon ist, dass man das “Equipment” Jlog komplett neu im Terminal einlernen muss, wenn man von Conf #0..2 auf #3 wechselte, und umgekehrt.
Bug #2
Das betrifft nur die JETI Sender. Im Gegensatz zur Profibox kann der Anwender ja die Datendisplays zunächst nicht selbst (manuell) aus dem Angebot des Sensors (“Equipment” == JLog) wählen. Stattdessen gibt es erst einen Scan des Senders, “AUTO” genannt,  nach angebotenen Datendisplays (“Sensoren” in JETI’s Sprachgebrauch), aus denen danach manuell die Displays ausgewählt werden können, die zur Anzeige gebracht werden sollen.
Nun passiert leider sehr häufig Folgendes, nicht nur mit JLog, auch mit Sensoren von JETI:  Der Sender findet alle Datendisplays, nur mit dem ersten (Display-ID 1) hat er Probleme, es erscheint nicht zur Auswahl. Der Bug in den Senderfirmwares scheint dann in Erscheinung zu treten, wenn das Terminal (der Sender) eine “EX” Data Message für ID1 vor der zugehörigen textuellen Definition als “EX” Text Message für ID 1 zu sehen bekommt. Wie gesagt, natürlich sendet ein Sensor die “EX” Text Messages sehr viel seltener als die “EX” Data Messages. Dadurch ist es sehr wahrscheinlich, dass der Bug sein Unwesen entfalten kann.
Hier hilft nur Geduld und Wiederholung des Scans (“AUTO”), vorher löscht man jeweils das Gelernte im Terminal (Sender). Irgendwann hat man Glück, und der Sender sieht die “EX” Text Message für ID 1 VOR einer “EX” Data Message für ID 1.  –  Schon seltsam, dass JETI das bisher nicht fixte..

Die Kommentarfunktion ist geschlossen.