Da es sich nicht im JLog-Manual findet und offenbar immer wieder zu Fragen beim Einrichten führt, hier noch mal konzentriert:
Wegen das Anschlusses des JLog an den Telemetriebus (Empfänger) siehe hier, inzwischen auch hier, hier und hier.
Zunächst: Alle beteiligten Komponenten müssen dasselbe HoTT-Protokoll sprechen, v3 oder v4, hier v4, - also JLog2, HoTT-Empfänger und -Sender, auch andere HoTT-Sensoren, wenn die sich mit auf dem Telemetriebus befinden sollen. Das betrifft auch eine SmartBox an einem HoTT-Tx-Modul (umgerüsteter Sender). Also: Firmware-Upgrade.
———————————————————————————————————————————————————————————————-
Da das komischerweise, obwohl kinderleicht, immer wieder zu Fragen führt, hier noch mal ausführlich, - insofern unangemessen ausführlich für das eigentliche Thema HoTTv4.
Die momentan aktuelle HoTTv4-Standard-Firmware für JLog2 ist die. (Der Konfigurator JLC sollte aktueller Version sein.)
Die Datei wird in die Wurzel des SD-Dateisystems (ganz oben) kopiert, der Logger flasht sich selbst beim nächsten Start. Flashen: Die rote LED blinkt ca. 15s, danach startet er, zunächst 5-sekündige “LED-Show” mit allen 3 LEDs während der Warteschleife gegen “Crazy Voltage” (durch GreenCaps, insbesondere im Zusammenhang mit einem “Antiblitz-Widerstand”), danach sollte die grüne LED dauerhaft schnell blinken, wenn gültige Daten vom JIVE empfangen werden. Wenn nicht, geht die grüne LED nach 5s Timeout (brennt zuvor stetig) aus. Danach zwinkert evtl. die orange LED, wenn ein JLog-eigener Sensor konfiguriert wurde, der Logger läuft dann auch ohne JIVE, auf eigener Zeitbasis. Die orange LED zwinkert mit JIVE (mit blinkender grüner LED) ansonsten mit jedem Aufzeichnen eines Records im Logfile. Sie brennt dauerhaft als Anzeige einer General-Alarm-Bedingung, wenn einer der konfigurierten Alarme vorliegt. Nach dem Flashen überprüfen, ob der Logger die richtige Firmware hat, welche, steht in “version.txt” auf der SD! Immer nur EINE Flash-Datei auf der SD halten, am besten nach dem Flashen gleich löschen. Grund: Befinden sich mehrere Dateien mit unterschiedlichen Firmwares auf der SD, würde sich der Logger mit jedem Start neu (anders) flashen. Das liegt daran, dass der Logger beim Start IMMER nach einer Flash-Datei schaut, sich mit einer gefundenen flasht, wenn die enthaltene Firmware (-Version) unterschiedlich ist zu der, mit der er aktuell geflasht ist. Ein Flash-Datei mit identischer Version wird ignoriert. (Der Name einer Flash-Datei ist dabei egal, sie muss nur die richtigen inneren Merkmale haben, z.B. für das Device bestimmt sein.)
Obiges ist natürlich der Weiterentwicklung unterworfen, teilweise inzwischen veraltet: Statt “JIVE” könnte dort auch “Castle Creations Regler” oder “HiTec Stromsensor” stehen und die aktuellen Releases findet man grundsätzlich im Download-Bereich, während obige direkte Links natürlich inzwischen längst veraltet sind. Heute, 9.3.2013, ist die aktuelle JLog2-Firmware z.B. für den JIVE die, für einen Castle Creations ESC die, mit einem HiTec Stromsensor anstatt JIVE oder CC die, und der zugehörige Konfigurator JLC5, im Augenblick Version 5.0.0.16, findet sich hier. Weiterentwicklung ist gut für den User, neue Funktionen, und alles geschenkt, aber der gute User muss natürlich auch ab und zu mal schauen, was es Neues gibt für sein Gerätchen, es neu flashen. “Ich habe das gerade neu gekauft” ist kein Argument, dat Tom (als wie Icke ) ist schneller als der Vertriebsprozeß.
JLog hinterlässt Funktionsmerkmale in der Config-Datei “CONFIG.txt”, sobald er einmal mit einer lief. Daher dann die Config-Datei auf der SD mit dem Konfigurator “JLC” öffnen und alle notwendigen Einstellungen vornehmen. (Bezüglich einiger Features in den Firmwares von JLog habe ich irgendwann aufgehört, immer alles “kalt” in JLC auswählbar einzubauen, um das Anwenden nicht unnötig zu belasten. Stattdessen hinterlässt eine Firmware eben ihre “Duftmarke” in der Config-Datei, die man beim Einladen in den JLC dann sieht, was entsprechende Funktionen konfigurierbar macht. Das betrifft im Moment teilweise “ImotShunt”, dann die Baudratenkorrektur am JIVE-Interface und die Telemetrie “HoTT”.)
Auch das ist mit den aktuellen Firmwares bzw. dem JLC im Download inzwischen etwas anders, aber nicht grundsätzlich. ———————————————————————————————————————————————————————————————-
So, gehen wir nun davon aus, dass alles HoTTv4 spricht:
JLog2 spricht HoTT in zwei Modi, Textmodus und Binärmodus mit einem grafischen Display, der Sensortyp ist jeweils “GAM“.
Zunächst gehe ich in’s Setup des Senders und wähle “GAM” als verwendeten Sensortyp aus: SET–>”Telemetrie”–>”Sensor wählen”: “GENERAL MODULE”. - Habe ich weitere Sensoren, wähle ich evtl. auch die an. - (Der Empfänger ist nicht abwählbar als Sensor. Der Sender ist immer dabei, man sieht ihn aber nicht als Sensor, nur (später, s.u.) zur Anwahl von Werten für wiederholende Ansage.) – Wegen eines Prinzip-Bugs in HoTT ist es ratsam, keine Sensoren anzuwählen, die man gar nicht angeschlossen hat! Tut man das doch, kann die Latenz von Sensordaten, wie sie am Sender erscheinen, teilweise dramatisch steigen.
JLog-Daten anzeigen am Sender:
Sensor – Textmodus:
SET–>”Telemetrie”–>”Einstellungen, Anzeigen”
Nun wähle ich mit den linken Tasten “UP/DOWN” den Sensor aus, also “GAM”. Beim ersten Mal muss ich mich evtl. über die Textseiten des Empfängers hangeln mit n-mal rechts “–>”. Es erscheint die erste Textseite von JLog2 als “GAM”, mit nochmal “–>” die zweite mit Min/Max-Werten, mit nochmal “–>” oder “<–” wieder Seite 1 usw.
Alarmebehaftete Werte werden invers dargestellt und der Alarm vom Sender angesagt, wenn man einen Ohrhörer oder Lautsprecher hinten eingesteckt hat, ohne wird die entsprechende Alarmtonfolge mit dem eingebauten Piezo Buzzer erzeugt. Der Buzzer schaltet sich über die 3,5mm-Klinkenbuchse des Senders ab.
Sensor - Binärmodus (Grafik):
Mit dreimal “ESC” verlasse ich den Textmodus des Senders in das Grunddisplay. Mit den linken “UP/DOWN” wähle ich nun den Sensor (“GENERAL”). Wenn bereits geschehen, reicht ein kurzer Klick auf “UP” oder “DOWN”. Die Grafikseite des “GAM” erscheint. Im Alarmfalle erscheint ggf. ein Subdisplay ausgewählter Werte, andere Grafik, größere Zeichen. Ich kann mich aber auch mit den linken “–>”/”<–” direkt in so ein Subdisplay begeben.
Sobald ich den Textmodus verlassen habe, wird der Sender mit dem nächsten Alarm evtl. ein grafisches Subdisplay zeigen, ich muss dazu nicht ein grafisches Basisdisplay, wie das von GAM, zur Anzeige angewählt haben. Sprich, Default des Senders ist der binäre Modus, somit kommt auch sofort eine aktivierte ständige Ansage wieder (s.u.), sobald ich den Textmodus verlassen habe. Alle angewählten Sensoren werden ausgewertet für Alarme und ständige Ansage, egal, ob und welches Binärdisplay ich mir gerade zeigen lasse. Akustische Alarme kommen, wie gesagt, immer, egal, ob Binär- oder Textmodus. Nur das Aufpoppen eines grafischen Subdisplays erfordert, dass sich der Sender im Binär- und nicht Textmodus befindet. Das ist ja logisch, denn im Textmodus übernimmt der Sensor das Visuelle komplett. Die grafischen Subdisplays sind shared über jeweils relevante Sensortypen.
Die Frage kommt immer wieder, ob man diese Subdisplays für Alarme im Sender abschalten kann: Nein.
Nun noch die Wertebelegung durch JLog2 im grafischen GAM-Display, denn das ist ja JLog nicht auf den Leib geschneidert, muss teilweise “missbraucht” werden:
AKK1: Ubat
AKK2: Ubec
T1: Fet-Temperatur Temp-PA
T2: BEC-Temperatur Temp-BEC
Die 4-stufige grafische Kraftstoffanzeige ist die relative Reserveanzeige zum eingestellten mAh-Alarmwert, also leer bei Erreichen/Unterschreiten der mAh-Alarmschwelle, i.Allg. bei 80% Nennkapazität gewählt. Eine SmartBox zeigt hier zusätzlich numerisch die verbleibenden mAh an, das Display eines Senders nicht.
Auf der rechten Displayseite haben wir einen alternierenden Teil aus zwei Displays:
A-Teil mit den Zellenspannungen: JLog misst z.Z. keine Einzelzellenspannungen, die 6 Wertepositionen werden hier anders verwendet:
Zelle1: externe Temperatur 1 (JLog-eigener Temperatursensor)
…
Zelle 5: externe Temperatur 5 (JLog-eigener Temperatursensor) Die Anzeigen können nur in 0.02-Schritten erfolgen, es gibt also nur geradzahlige Temperaturen, “0.24V” sind 24°C, “1.26V” sind 126°C, z.B. Negative Werte können nicht dargestellt werden, Temperaturen unter Null kommen als “0.00V” für 0°C. Wurde als Sensor in JLC “Voltage” oder “Volt+Temp” angewählt, dann führt Zelle 1 die gemessene Spannung 0..12,8V, “1.28V” entsprechen 12,8V, “0.84V” wären also 8,4V. Zelle 6: externe Drehzahl (JLog-eigener RPM-Sensor) Auch hier nur 0.02-Schritte, anzeigbares Maximum ist 5100 UPM, 800 UPM kommen als “0.80V”, 5100 UPM als “5.10V”, z.B. Ganz unten im A-Teil des alternierenden Display-Bereichs haben wir “RPM-Uni”, also untersetzte Rotor- oder Propellerdrehzahl.
B-Teil:
Höhe: PWM 0..100%, also “100m” == 100%
m1 bzw. m/s: Wird nicht besetzt durch JLog. *)
m3 bzw. m/3s: Gas 0..100%, also “100 m/3s” == 100%
Unten haben wir:
Ubat in V
Imot in A
mAh (nur auf 10mAh genau angezeigt, also 10mAh-Schritte) - Die SmartBox zeigt hier auch die “mAh”-Maßeinheit.
( *) ”m/s” darf nur mit entsprechenden Vario-Werten besetzt werden. Nicht nur der Sensor VARIO, auch Graupners GPS, EAM und GAM haben einen barometrischen Drucksensor und liefern ergo “m/s”, auch ein 3rd-Party-Sensor wie SM Unilog2 oder GPS-Logger. Man würde die Variotöne und die visuellen Ausgaben stören, würde man hier artfremde Daten anbieten. “m/s” ist also ein Wert, den der Sender über ALLE beteiligten Sensoren berücksichtigt. Das ist ganz unabhängig davon, ob sich ein Sensor binär als VARIO darstellt, auch, wenn nur ein VARIO (Sensor-Adresse) das große VARIO-Display bedient. Das kleine VARIO-Display wird durch alle Sensormoduln gefüttert, die “m/s” liefern.)
Bitte beachten: Da JLog2 sich als Sensortyp “GEM/GAM” darstellt, darf sich natürlich nicht ein weiterer GEM oder GAM auf dem Telemetriebus befinden, weder so ein Graupner-Sensor, noch ein 3rd-Party-Sensor, der als GEM/GAM auftritt!
JLog-Firmware mit HoTT enthält nicht mehr den “jbJLC”, den Online-Konfigurator (ohne PC) via JETIduplex, JETIbox oder Unidisplay! Das war einfach eine Platzfrage im Speicher des Loggers.
Nur zur Info: Sobald Graupner/SJ den neuen Sensor “ESC” in seiner vereinbarten Endversion in die Senderfirmwares gebraucht hat, wird JLog wahrscheinlich von GAM auf ESC wechseln. Leider geht dabei die grafische Spritanzeige verloren.
Das war’s eigentlich schon, bleiben noch die Feinheiten:
Zunächst noch mal zu den Alarmen:
Im Binärmodus (Grafik) gibt es ja keine Interaktion mit dem Sensor, der sendet seine Daten auf Abfrage auf dem Bus, einschließlich aktiver Alarme, und das war’s. Man kann also einen aktiven Alarm sensorseitig nicht stoppen.
Im Textmodus geht es, die Akustik eines Alarms zu stoppen: Mit rechts “DOWN” (“DEC” an der SmartBox) wird der gerade akustisch erklingende Alarm gestoppt, die visuelle Anzeige bleibt (inverse Zeichen der betreffenden Displayposition). Mit rechts “UP” (“INC” an der SmartBox) werden alle gerade aktiven Alarme akustisch gestoppt. - Verschwindet die Alarmbedingung eines Wertes und kehrt dann wieder, geht das Stopp-Spiel von vorne los, wenn vom Piloten gewünscht. Das ist eine spezifische Softwarefunktion des Sensors JLog2 als “GAM”, nicht vom Sender.
Ständige Ansage von Werten:
Das ist rein eine Funktion des Senders, ein Sensor liefert nur zu, und zwar nur im Binärmodus, also nur, wenn sich der Sender NICHT im Textmodus befindet! Seit HoTTv4 erfolgt in einem Textmodus einfach gar keine der konfigurierten wiederholenden Ansagen mehr, in HoTTv3 kamen die Ansagen noch, aber ein Wert blieb statisch auf dem bei Eintritt in den Textmodus. Grund: Binär- und Textmodus sind alternativ ausschließend. Der Empfänger, als Telemetriebusmaster und Stellvertreter des Senders, fragt entweder nur Sensoradressen im Binärmodus oder nur im Textmodus ab, nicht gemischt. Textmodus ist freie textuelle Gestaltung von Displays durch Sensoren (wie bei JETI v1.0 generell und JETI v1.1 außerhalb der “Hidden Messages”), nur Werte aus einem Sensordatenblock im Binärmodus sind für den Sender interpretierbar, können also auch angesagt werden. - Im Falle eines Alarms werden keine Werte angesagt. Die Alarmreaktion des Senders ist identisch im Binär- und Textmodus.
In diesem Zusammenhang, SmartBox: Die grafischen Displays der SmartBox, im Augenblick nur englischsprachige Firmwareversion, sind soweit fast identisch zum Sender, die Bezeichnungen in den Menüs differieren etwas. Die SmartBox kann über einen eingebauten Piezo Buzzer dieselben Alarmtonfolgen liefern wie ein HoTT-Sender.
Die Box im grafischen Modus ist zum Betrieb an einem HoTT-Tx-Modul gedacht, an einem Voll-HoTT-Sender kann sie nur ein grafisches Zweitdisplay sein, in einem Textmodus funktionslos. Man kann mit dem Sender-Display im Setup des Senders sein, während die Box eine grafische Telemetrieseite zeigt. - Im Textmodus kann die SmartBox zum Setup oder zur Datenanzeige direkt an einen Sensor angeschlossen werden, aber nicht an einen Empfänger. Grund: Beide sind Busmaster, Empfänger und Box. - Die grafischen Displays der Box (Binärmodus) sind nicht von Sensoren im direkten Anschluss bedienbar, obwohl die Box die Sensoren als Busmaster abfragt. Grund ist, dass die Box zusätzliche Daten in einem Header vor den Sensordaten erwartet (Rx Sensordaten), die nur ein HoTT-Tx-Modul liefert, bzw. ein HoTT-Sender beim Betreiben der Box als Zweitdisplay. (Im Betrieb der SmartBox an der JLog-eigenen Telemetrie “JTX” kann sie auch grafisch anzeigen.)
Nun zum Einrichten von sich wiederholenden Ansagen:
Zunächst muss natürlich der betreffende Sensor, GEM/GAM, EAM, VARIO, GPS (Empfänger ist immer aktiv), angewählt sein. Spätestens seit HoTT v4 sind mehrere gleichzeitig möglich.
Dann sind die Werte auszuwählen, die der ständigen Ansage z.V. stehen sollen: SET–>”Telemetrie”–>”Auswahl Ansagen”, dann –><Sensor>–>Werte. – ”Wiederholrate” definiert, alle wieviel Sekunden ein gerade gewählter Wert angesagt wird. Hier nichts unter 10 Sekunden einstellen! Außerdem betätigt man zu dessen Konfiguration einen Schalter, der im geschlossenen Zustand die wiederkehrende Ansage aktiviert - ”Nächste Ansage” definiert einen Schalter, möglichst einen mit nur einer Ruheposition (Taster), der unter den zuvor zur Ansage ausgewählten Werten weiterschaltet, reihum. - ”Vario” definiert einen Schalter, der die Ausgabe der Variotöne aktiviert.
Der Sprachausgabemodul eines HoTT-Senders kennt weder Prioritäten (Alarme vor wiederkehrender Ansage, z.B.) noch ein Queueing, er hat also keinen Auftragspuffer für Sprachausgaben. Somit wird eine Anforderung zur Sprachansage ignoriert, wenn gerade gesprochen wird. Die wiederkehrende Ansage und die Alarme der verschiedenen Sensoren (Sensormoduln) sind aber asynchron zueinander und wetteifern somit untereinander um die Sprachausgabe, sich dabei gegenseitig blockieren könnend. (Auch die Variotöne sind in diesem Sinne eine “Sprachausgabe”!) – JLog2 als “GAM” lässt einen aktiven Alarm nicht ständig anstehen, sondern nur kurz in seinem Datenblock in Abfrage durch den Empfänger, dann nimmt er ihn wieder weg und wiederholt ihn nach 6 Sekunden, wenn die Alarmbedingung noch bestehen sollte. Damit ist gewährleistet, dass eine wiederkehrende Ansage mit 2..3 gleichzeitig aktiven Alarmen vom Multisensor JLog als “GAM” noch koexistieren kann, ohne, dass der Eine den Anderen vollständig aushebelt. Alarme haben Priorität, daher sollte die ständige Ansage nicht häufiger als alle 10 Sekunden wiederkehren. Ab 3..4 aktive Alarme EINES Sensors wie JLog fangen die Alarme an, die ständige Ansage vollständig zu blockieren. Das soll so sein, jedenfalls besser als andersherum.
) ist schneller als der Vertriebsprozeß. 
