HoTTv4
Im Grunde genommen beschreiben die unten stehenden Screenshots schon alles, was man wissen muss.
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.
HoTT verwendet einen sog. 1-Wire-Bus, er besteht nur aus “Masse” und “Signal”. Auf der Signalleitung wird simplex wechselseitig asynchron-seriell gesendet und empfangen, mit 19.200 Baud. Der rote Draht ist auch belegt, aber kein Bestandteil des Busses, 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 Telemetriebus 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!
.
HoTTv4 und die Sensoren
HoTTv4 kennt derzeitig 5 Sensortypen, GAM, EAM, VARIO, GPS und ESC. Von jedem Sensortyp darf sich immer nur ein Sensor auf dem Telemetriebus befinden! Der Grund ist, dass der Empfänger diese Sensoren mit ihren typspezifischen Adressen anspricht, jeder Sensortyp hat eine fixe Adresse für den Binärmode (pseudografisches Hauptdisplay plus verschiedene Subdisplays), eine weitere für den Textmode. Beide Modes sind exklusiv, der Bus kann sich, gesteuert durch den Empfänger, kommandiert vom Sender, immer nur im Binär- oder im Textmode befinden. Ein Sensor erkennt anhand der vom Empfänger zur Ansprache verwendeten Adresse, welcher Mode gerade abverlangt ist.
Der Binärmode ist oneway, im Textmode wird interaktiv mit dem gerade adressierten Sensor kommuniziert, der Sensor bekommt den Status von 4 Tasten und eine Kombination dieser Tasten mitgeteilt.
Textmode
Im Textmode kann ein Sensor seine Displays (beliebig viele Seiten) im Rahmen des vorgegebenen Zeichensatzes (ASCII) und der zeichenweisen Struktur (8 x 21 Zeichen) frei gestalten, auch das inverse Darstellen von Zeichen ist möglich, um deren Status zu markieren. Der Sensor kann den Anwender durch seine Displays anhand der erfahrenen Tastencodes navigieren lassen. Auch ein Setup des Sensors ist somit auf diesem Wege möglich.
Binärmode
Im Binärmode hat ein Sensor, je nach seinem Typ, binäre Daten in fixer Form in einer vorgegebenen Maske zu senden, nicht-interaktiv. Der Sender als Terminal, bzw. eine SmartBox, sorgt für die Darstellung. Da die Daten binär kodiert sind, kann sie der Sender also auch inhaltlich interpretieren, den Wert eines Datums inklusive eventueller Kommastelle, die Einheit, Ampere, z.B. Binäre Darstellung des Datums und Einheit sind fest vorgegeben. Jedes Datums innerhalb einer “Maske”, in die ein Sensor im Binärmode ausgibt, hat im Sender einen fixen Namen, wie “Sensor 1″ und “Sensor 2″, z.B. Aufgrunddessen ist der Sender in der Lage, vom User ausgewählte Werte zu sprechen, was in einem einstellbaren Intervall geschieht, außerdem definiert man einen Schalter, der die Funktion auslöst. – Im Textmode hingegen, der ja, wenn aktiv, exklusiv ist für den gesamten Bus (alle Sensoren), können Daten in den Displays der Sensoren vom Sender nicht interpretiert werden. Aktivierte ständige Sprachausgaben von Daten werden daher gestoppt, solange man sich im Textmode befindet.
Der Binärmode ist der Default Mode, in dem sich der Sender befindet, wenn man ihn einschaltet. Im Binärmode fragt der Empfänger alle 200ms die Adresse eines Sensors an, der zuvor auf dem Bus gefunden wurde, – reihum. Im Textmode wird immer nur der gerade selektierte Sensor abgefragt, – alle 800ms. Natürlich erhöht sich im Binärmode die Latenz proportional zur Anzahl der Sensoren auf dem Bus, Maximum ist 1 Sekunde, 5x 200ms.
Sensor-Erkennung
Vor geraumer Zeit führten die Firmwares der HoTT Empfänger und Sender ein, dass ein Sensor nicht mehr durch den User am Sender aktiviert werden kann, stattdessen erfolgt ein Scan nach gerade vorhandenen Sensoren. Sender und Empfänger tun das in Zusammenarbeit, Empfänger als Ausführender, er hat den Bus, ist der Busmaster. Ein Scan wird jedes Mal ausgelöst, wenn Sender und Empfänger sich im Telemetrie-HF-Kanal koordiniert (Restart) wiedersehen, zuvor keine Verbindung bestand. Sei es nun, dass der Sender an ist, während der Empfänger erst eingeschaltet wird, sei es dadurch, dass man den Sender kurz aus- und wieder anschaltet. Der Scan erfolgt durch Abfrage aller binären Sensoradressen der 5 bekannten Typen durch den Empfänger, – reihum alle 5 Adressen. Antwortet ein Sensor mit vollständiger “Maske” (Frame), und ist diese gültig (Checksumme stimmt), dann registriert der Empfänger diesen Sensortyp als auf dem Bus vorhanden und teilt dies dem Sender mit. Der Scan währt 16 Sekunden, – während dieser Zeit ist die Update Rate der Sensordisplays im Sender beschränkt. Es ist auch ratsam, während des Scans nicht bereits das Binärdisplay eines Sensors am Sender zur Anzeige selektieren zu wollen. Es könnte dazu führen, dass das Ganze einen bereits gesehenen Sensortyp wieder verliert.
Alarme
In beiden Modes können Sensoren Alarme senden. Alarmbildung und -meldung sind allein Sache der Sensoren. Der Sender nimmt sie nur entgegen und gibt sie aus. Befindet sich kein Hörer oder Lautsprecher in der Audio-Klinkenbuchse des Senders, dann piept dieser je Alarmtyp eine Tonfolge, ansonsten erfolgt eine Sprachausgabe, z.B. “Kapazität” für einen mAh-Alarm. Der momentane Wert wird dabei nicht gesprochen. Sprachausgabe von Alarmen erfolgt auch, wenn man sich gerade im Textmode befindet.
JLog als HoTT Sensor
JLog kann als HoTT Sensortyp GAM oder als ESC auf dem Telemetriebus erscheinen, daher gibt es je ESC-Typ zwei Firmwares für JLog mit HoTT-Telemetrie.
Im Textmode von JLog generierte Displays sind identisch in beiden Sensortypen, JLog als GAM oder als ESC. Das zweiseitige Textdisplay von JLog dient nur der Ausgabe, wird nicht zum Setup von JLog verwendet, – das besorgt sein Konfigurator JLC. Alarmbehaftete Werte im Textdisplay (Seite 1) erscheinen in inverser Darstellung.
Alle Werte, auf die JLog per JLC Alarmschwellen definieren kann, haben einen entsprechenden spezifischen HoTT Alarmtyp, als Tonfolge vom Sender ausgegeben oder als Sprachausgabe. Das sind Alarme auf mAh, Ubat, Ubec (Dip Alarm), tFET, tBEC (wenn ein HV²BEC angeschlossen ist), Temperaturalarme auf JLog-eigene Temperatursensoren 1..3, Geschwindigkeitsalarme für Stall Speed und Max Speed, wenn ein Speed Sensor (Prandtl Sonde) SM#2560 als JLog-eigener Sensor konfiguriert ist. Außerdem gibt es einen Spannungsalarm analog dem auf Ubat als “General Alarm” auf Negativmeldungen vom JLog-eigenen Sensor CVS16 im Betrieb als Zellenspannungssensor an einem Battery Pack, bis zu 16S. CVS16 meldet JLog, JLog als GAM oder ESC meldet HoTT. Außerdem generiert JLog selbst einen Spannungsalarm aus seiner Alarmschwelle auf LCV (Lowest Cell Voltage), was CVS16 auch liefert.
Alarmtypen, ihr Mapping auf Voice Files, sind eigentlich als global im HoTT Protokoll definiert, – unabhängig vom Sensortyp, der einen Alarm meldet. Trotzdem durchbrach SJ die Protokollspezifikation beim Implementieren des HoTT Sensors ESC im Sender. “ESC” bedient nicht alle Alarmtypen mit dem entsprechenden Mapping auf Voice Files, stattdessen wir dann ersatzweise eine Nummer gesprochen, z.B. “19″. Das ist eindeutig ein Bug, kein Feature.
Voice Module - Racing Conditions
So ein Modul kann natürlich immer nur anstehende Messages eine nach der anderen abarbeiten. Leider ist es auch in HoTT so, dass es weder ein Queueing im Sender noch ein Prioritätssystem gibt, Alarm- vor Intervallansagen, z.B.
Es gibt keine Koordinierung der Resource Requests. Innerhalb ein und desselben Sensors, wenn der mehrere Alarme gleichzeitig anstehen hat, ginge das Koordinieren. JLog macht das, HoTT Sensoren von Graupner/SJ aber nicht. Sie liefern einfach in jedem Data Frame die Alarm Conditions statisch, solange die betreffenden Alarmbedingungen bestehen, überlassen alles dem Sender, der aber nicht vorbereitet ist.
Zwischen den Alarmen von verschiedenen Sensoren auf dem Bus kann es eh keine Koordinierung geben, solange das nicht explizit vom Protokoll implementiert ist.
Hinzu kommen aber auch noch die Resource Requests auf den Voice Module aus dem Sender selbst, eingestellte Intervallansagen und Vario-Funktion, die hohe Priorität haben sollte und hat. Ein Problem ist, dass das Setup im Sender erlaubt, viel zu kurze Intervalle für ständige Ansagen einzustellen.
JLog als GAM oder ESC lässt daher jeden seiner Alarme nur 1+ Sekunden auf dem Bus stehen, nur solange, dass er auch bei 5 Sensoren auf dem Bus vom Empfänger/Sender z.K. genommen werden kann. Dann nimmt er ihn wieder weg, wiederholt das alle 6 Sekunden. Hat er mehrere Alarmtypen aktiv, koordiniert er sie (intern), sodass alle zusammen nicht öfter als im besagten 6-Sekunden-Intervall Bedarf am Voice Module anmelden.
Die Wiederholzeit einer fortlaufenden Ansage sollte daher nicht kleiner als 10 Sekunden gewählt werden! Tests zeigten, dass man so i.Allg. gut miteinander auskommen kann, inkl. Vario-Funktion, – Ausnahmen bestätigen die Regel. 
Vario-Funktion
Alle Sensortypen bis auf ESC haben in ihrem binären Data Frame ein Datenfeld “m1″, m/s. Der Sender berücksichtigt diesen Wert von ALLEN Sensoren, die ihn besetzen (ungleich Null), um daraus sein “Gequietsche” zu speisen. Also nicht nur ein Sensortyp VARIO speist das aus seinem Drucksensor, auch GAM, EAM und GPS, wenn sie sich auf dem Bus befinden. JLog muss sich daher enthalten, als GAM “m/s” als Display zu verwenden, hier hätte ansonsten Speed/kph gut hineingepasst. (Leider funktioniert die Ausgabe in GAM Subdisplays für Speed, LCV, LCN und zweite Drehzahl immer noch nicht, obwohl bereits Anfang 2012 in der Definition des GAM Data Frames (“Maske”) beschrieben durch SJ.)
.
Unten stehend die Telemetriedisplays von JLog. Legende:
Ubat * ….. Antriebsspannung, vom ESC als Sensor an JLog geliefert, – Gesamt-Pack-Spannung, wenn ein CVS16 angeschlossen ist und im “Pack Mode” betrieben wird
Ubec * ….. BEC-Ausgangsspannung, u.U. vom ESC als Sensor an JLog geliefert, – vom HV²BEC, wenn ein solcher angeschlossen und an JLog konfiguriert ist
tFET …… ESC Endstufentemperatur
tBEC * ….. BEC Temperatur, wenn vom ESC als Sensor an JLog geliefert. Temp. des HV²BEC, wenn ein solcher angeschlossen und an JLog konfiguriert ist. extT1, wenn ein JLog-eigener Temp.sensor konfiguriert ist, und HV²BEC is nicht konfiguriert. “ESC”: Prioritätenreihenfoge ist somit: tBEC vom HV²BEC, extT1, ESC’s tBEC. “GAM”: extT1 hat ein eigenes Display-Feld.
mAh ……. verbrauchte Kapazität, vom Sender in Schritten von 10mAh angezeigt
Fuel Gauge .. Eine 4-sufige “Tankuhr”, die JLog befüllt, sofern er eine mAh-Alarmschwelle kennt (->JLC). “Voll” skaliert sich aus der konfigurierten Alarmschwelle.
PWM …… “Internes Gas” des ESC, von diesem u.U. an JLog geliefert.
throttle …. “Gas”, via Empfänger vom Sender an den ESC, von diesem u.U. an JLog reportet. (Ein Castle Creations ICE/EDGE sendet keinen Gaswert, der auf sein Verständnis des Gasimpulses schließen lässt. JLog errechnet einen Gas-Absolutbetrag auf Basis der Annahme, dass für 100% der Gasimpuls 1940 Mikrosekunden lang ist, 1100 für 0%.)
Imot ……… Motor- bzw. Batteriestrom, reportet durch den ESC an JLog
LCV ……… Lowest Cell Voltage. Bestimmt durch einen CVS16, reportet an JLog, wenn ein CVS16 angeschlossen und an JLog konfiguriert ist
LCN/50 ….. Nummer der Zelle (1..16), für die LCV gilt. S.o. – “0.02″ entspricht dem Wert “1″, “0.32″ entspricht “16″
extTn/100 .. 1..3 Temperaturwerte aus JLog-eigenen Temperatursensoren, wenn diese angeschlossen und konfiguriert sind. “0.20″ entspricht “20 °C”
extRPM/1000 .. Mit einem JLog-eigenen Sensor gemessene Drehzahl, wenn ein solcher Drehzahlsensor angeschlossen und konfiguriert ist. “0.50″ enspricht dem Wert “500″
…………….. Achtung! Die 6 eigentlich für Zellenspannungen gedachten Displays zeigen nur modulo 0.02 an!
rpmRotor .. Im Log (LogView) von JLog “rpmUni” genannt. JLog bekommt vom ESC eine 2-pol-normalisierte Drehzahl. Er wendet die ihm per JLC bekannte magnetische Polzahl des Motors an und erhält “rpmMotor”. Dann wendet er darauf das Untersetzungsverhältnis (Ratio) an, dass ihm durch JLC in einer vom Anwender gewählten Form bekannt gemacht wird. Das Ergebnis ist “rpmUni(versal)”, was beim Heli “rpmRotor” entspricht.
.
