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
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!
.
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.
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)
.
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
.
Spezifische Displays
Config #0 - kein HV²BEC, kein CVS16
.
Config #0 - HV²BEC, kein CVS16
.
Config #0 - kein HV²BEC, CVS16
………. CVS16 im Pack Mode
………. CVS16 nicht im Pack Mode
.
………. weitere Sensordaten
.
Config #0 - HV²BEC + CVS16
………. CVS16 im Pack Mode
………. CVS16 nicht im Pack Mode
.
………. weitere Sensordaten
.
Config #1
.
Config #2
.
Config #3 - kein HV²BEC, kein CVS16
Config #3 - HV²BEC, kein CVS16
Config #3 - kein HV²BEC, CVS16
Config #3 - HV²BEC + CVS16
.
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”
