Konfigurator JLC

Grundverständnis des Konfigurierens von JLog

Das Konfigurieren von JLog erfolgt offline zu JLog mittels des Konfigurators JLC. Der Mittler der Konfigurationsdaten zwischen beiden ist die Datei “CONFIG.txt” im Wurzelverzeichnis des Dateisystems (FAT16) der SD.

Startverhalten von JLog
Nach Reset bzw. Powerup von JLog startet zunächst ein residentes Programm (nicht änderbar durch Update by User), der “Bootloader”. Der Bootloader schaut, ob eine SD drin steckt (Kontakt im SD-Slot), wenn ja, initialisiert er deren Elektronik. Dann mountet er das Dateisystem auf ihr und schaut, ob er eine Updatedatei findet. Dabei ist der Dateiname egal. Der Bootloader erkennt eine Updatedatei an ihrer Position im Dateisystem (im Wurzelverzeichnis), an deren Länge (60kByte) und vor allem an Merkmalen in deren Inhalt. Ein Merkmal ist, für welche Hardware (Plattform) die Datei ist (i.Augenblick JLog1, 2, 2.5, 2.6, HTI), das andere ist die Versionskennung, Major und Minor ID. Nur, wenn die Plattformkennzeichnung stimmt und die Versionskennung eine andere ist als die der gegenwärtig im Speicher (FlashROM) von JLog befindlichen Firmware, wird eine Updatedatei auch zum Flashen verwendet. Er flasht sich also mit einer bestimmten Updatedatei immer nur einmal, danach ignoriert er sie.  –  Am besten die Datei nach dem Flashen von der SD löschen. Nie mehr als eine Updatedatei auf der SD belassen! Sonst würde sich JLog mit jedem Start mit der Datei flashen, die jeweils eine andere Version, als in seinem Speicher befindliche, enthält! (Die Firmware ist verschlüsselt, der Bootloader entschlüsselt sie beim Flashen.)

Sobald der Bootloader startet, macht er die rote LED an. Sie wird erst wieder durch die Applikation (“Firmware”) ausgeschaltet, wenn der Bootloader an diese übergeben hat. Beim Flashen, dauert ca. 15 Sekunden, blinkt die rote LED 1x für je zwei geflashte Speicherseiten.

Der Bootloader eines JLog2.6GW hat auch noch eine andere Aufgabe, das “Enabling” anhand einer Enabler-Datei, z.B. für GW–>FULL. Ob es sich bei einer Datei im Wurzelverzeichnis um einen Enabler handelt, erkennt der Bootloader selbst. Passt der Enabler auf das “Individuum” JLog (auf die Device ID) und ist der enthaltene “Enabling Request” passend (sinnvoll) zum gegenwärtigen Enabling Status des JLog, dann führt der Bootloader das durch die Datei angeforderte Enabling durch. (“Unpassend” wäre z.B. ein Enabler von LO auf FULL, obwohl der gegenwärtige Enabling Status GW und nicht LO ist. Ebenso unpassend wäre ein Enabler auf LO, obwohl der JLog bereits FULL ist.)
Ist ein Enabling erfolgt, geht die grüne LED an. Ist der dadurch erreichte Enabling Status schon vorher existent gewesen (z.B.: war schon FULL und sah einen Enabler auf FULL), dann geht zusätzlich die orange LED an, um das zu signalisieren, was aber nichts Schlimmes ist.

Eine weitere Aufgabe ist, dass der Bootloader einen Bus vom Typ I²C (auch TWI genannt) an seiner X-Bus Buchse bzw. auf den beiden Signalpins seines Port “OPTions” (“Sensor/Alarm” bei JLog2) aufhält (einfriert). Erst die zum Verlassen des Bootloaders gestartete Applikation hebt die Sperre wieder auf. Zum Grund siehe SPEKTRUM Telemetrie.

Ist das geschehen, ob nun Flashen stattfand oder nicht, startet der Bootloader die Applikation, also das, was man mal als “Firmware” flashen ließ.

Die erste Amtshandlung jeder Firmware ist, wenn sich eine SD im Slot befindet, ein 5-sekündiges Blinken mit 3 LEDS, rot, orange, grün. Das passiert, bevor die Applikation die SD überhaupt das erste Mal anfasst. Etwas anderes als Blinken macht der JLog in den 5 Sekunden nicht. Das Blinken soll den Anwender “bei Laune halten”. . Es handelt sich um eine Warteschleife, Warten auf Beruhigung der Betriebsspannung, “Loop against Crazy Voltage” nenne ich das. Der Grund ist folgender: So mancher Anwender hängt da immer noch blank hochkapazitive Kondensatoren an den BEC-Ausgang, und on top evtl. noch einen “Antiblitzwiderstand”. Die Spannung kriepelt sich langsam hoch, der BEC sieht multibel einen Kurzschluss, schaltet x-mal die Ausgangsspannung weg. JLog’s Herz ist ein Microcontroller, und dem wurde eine sog. “Brownout” Spannungsschwelle verpasst. Fällt die Betriebsspannung unter diesen Wert, geht er temporär Schlafen, um keinen Mist machen zu können. Allerdings hat eine SD auch Elektronik, und die wird i.Allg. etwas früher (bei etwas höherer Spannung) bereits zum Zombie. Die Wirkung wäre u.U., dass deren “besoffene” Elektronik wild auf der SD rumschreibt und dabei deren Dateisystem zerstört, oder eben einzelne Dateien zerstört, wie z.B. CONFIG.txt!

JLog startet und läuft auch ohne SD, das geht entsprechend schneller, nur kann er dann natürlich keine neue Konfiguration lernen bzw. nicht loggen. Alles andere bleibt davon unberührt.

Reset bzw. Restart des JLog:  Neben Betriebsspannung off/on geht das auch per SD. Wenn man in den unter Spannung befindlichen JLog eine SD steckt, löst das ein Reset aus, also Neustart.

Konfigurieren

Jetzt sind wir endlich am Ausgangspunkt, Konfigurieren des JLog via den “Vermittler” CONFIG.txt:
Startet JLog mit einer SD, und ist in deren Dateisystem, Wurzelverzeichnis, eine Datei namens “CONFIG.txt”, dann liest er sie ein, um eine evtl. neue Konfiguration zu lernen. Vor dem Auswerten stellt JLog jeden einzelnen seiner Kongurationsparameter auf einen jeweiligen spezifischen Default Wert, z.B. 6 Pole und Ratio 1:1. Beim Einlesen bewertet er jeden Parameter auf Sinnfälligkeit, korrigiert im Fehlerfall auf einen sinnigen Wert. Ist das geschehen, vergleicht er jeden Wert mit seinem “Gedächtnis”, einem nichtflüchtigen Speicher im Microcontroller. Hat sich ein Wert gegenüber dem Gedächtnis verändert, überschreibt er ihn in diesem. Hat er nicht sinnfällige Werte auf CONFIG.txt zuvor korrigiert, oder findet er nicht seine “Duftmarke” in der Datei (Duftmarke: JLog-Modell und Firmware-Typ), überschreibt er die Config Datei. Am Ende nimmt er die aktuellen Parameter als Ausgangsbasis und beginnt sein “normales JLog-Leben”.

Ohne SD-Karte nimmt JLog die Parameter aus seinem Gedächtnis.

Wir halten also fest:

• Die eigentliche Konfiguration befindet sich im “Gedächtnis” des Prozessors. Sie wird nur evtl. verändert anhand dessen, was JLog nach dem Start in CONFIG.txt vorfindet.
• Findet er keine Datei CONFIG.txt im Dateisystem, dann erzeugt er sie und befüllt sie mit den Parametern aus seinem Gedächtnis.
• Weitergehend: JLog erzeugt JEDE Datei, ob reguläre oder Directory, die er benötigt, selbst. Man kann ihm also eine leere SD anbieten.

Daraus könnte nun im Problemfalle eine verwirrende Konstellation entstehen:  Ist das Dateisystem richtig kaputt, kann JLog u.U. die Datei CONFIG.txt nicht ordnungsgemäß befüllen, wenn er sie neu erzeugen will, weil sie nicht existiert, oder wenn er einen Grund sieht, sie zu überschreiben. Es könnte passieren, dass eine leere Datei entsteht. Mit dem nächsten Start sieht JLog in Auswertung der leeren Datei gar keine Parameterwerte,  -  ergo “lernt” er die zuvor eingestellten Default Werte und brennt sie dann auch in sein Gedächtnis. Hier hilft nur:  SD formatieren mit dem SDformatter von sdcard.org.

So kann man verifizieren, ob JLog das lernte, was man ihm per JLC via CONFIG.txt beibringen wollte:

• CONFIG.txt von der SD löschen. (per Windows (File) Explorer)
• JLog dann mit der SD starten, warten, bis die “Lichtorgel” mit den 3 LEDs vorüber ist. JLog erzeugt die Datei neu und befüllt sie mit seinen Gedächtniswerten.
• SD in den PC und CONFIG.txt per JLC einlesen. Sollte dort nicht das drin stehen, was man ihm schon mal zum Lernen vorsetzte, dann mal per Windows Explorer gucken, ob die Datei nicht evtl. gar nichts enthält. In diesem Falle SD formatieren, JLog CONFIG.txt erzeugen lassen, in JLC einlesen, evtl. modifizieren, JLog wieder “zu fressen” geben, CONFIG.txt am PC wieder löschen, SD noch mal JLog geben, – und am Ende die Config Datei noch mal in JLC einlesen, – und siehe da..

JLC

JLC (JLog Configurator) ist ein sog.”Expertensystem”. Das bedeutet, was man mit JLC konfiguriert, ist IMMER sinnig und wird so mit JLog funktionieren. JLC kennt alle Abhängigkeiten des Setups, – vom JLog-Modell, von der geflashten Firmware, den Sensoren (ESC-Typ, JLog-eigene Sensoren) und des Telemetriesystems. “Mist machen”, geht nicht.

Gleichzeitig ist JLC DIE Instanz zum Lernen der Anwendung von JLog! Man kann damit alles durchspielen, sehen, was passiert, wenn, – ohne irgendetwas “kaputt machen” zu können. Gleichzeitig gibt es für JEDES konfigurative Element einen Hilfe-Text unten links im großen Text Window, außerdem Links zu Dokumentationen im Internet (JLog Home Page), JLC verwandelt sich dabei temporär in einen Browser. Dazu mit der Maus über ein Desktop Element von JLC fahren bzw. drauf klicken.

Aus dem oben gesagten resultiert:  Eine Config Datei sollte man grundsätzlich erst einlesen von der SD, dann bei Bedarf im JLC modifizieren und durch JLC zurückschreiben!  Es geht zwar auch, alles “vom grünen Tisch aus” zu machen im JLC (JLog-Modell und Firmwaretyp wählen) und danach die Datei mit JLC zu schreiben, aber nicht ohne Grund erscheint dabei ein Popup Window, was uns darüber belehrt, dass es mit vorherigem Einlesen besser wäre.

Seit JLC6 kann er sich automatisch updaten aus dem Internet. Es könnte aber lokale Gründe (Setup des jeweiligen Betriebssystems) geben, die dem im Wege stehen. Daher regelmäßig die Download Seite checken.

Im Augenblick (Ende April 2014) haben wir neben dem JLC4 für JLog1 zwei Releases JLC, – JLC5 für JLog2 und 2.5, JLC6 für JLog2.6. Es wird in Kürze eine Konsolidierung des “funktionellen Look&Feel” der Firmwares geben, Jlog2.6 Firmwares zurückgepiegelt in die für JLog2.5 und 2. Im Zuge dessen wird es auch wieder einen konsolidierten JLC geben, JLC7 für JLog2, 2.5 und 2.6.

Es wäre nun unnötig, viel zu aufwändig und im Widerspruch zum Zweck von JLC, auf jedes Desktop Element in jeder Konfiguration eingehen zu wollen. Vieles findet man bereits in den Dokumentationen der Sensoren.

Auf ein paar Elemente soll aber hier noch hingewiesen werden:

RESET  Setzt ein Flag in der Config Datei, der beim nächsten Auswerten der Datei durch JLog von diesem sofort wieder gelöscht wird. Er bewirkt, dass JLog beim nächsten Start alle Logs von der SD löscht und die laufende Logfile Nummer auf “0″ zurücksetzt. Er löscht dabei auch die Log Directories. Das erste Log Directory heisst z.B. “d000-510″, weil jeweils 511 reguläre Dateien (Log Dateien) in ein Log Directory geschrieben werden, das zweite dann “d511-1021″ usw. Diese Directories und ihr Inhalt werden gelöscht, sonst aber nichts auf der SD.

LogStop  Das Dateisystem ist potentiell gefährdet, kann inkonsistent werden, wenn dem Gerät während eines Schreibvorgangs der Saft abgedreht wird. Das Gerät, JLog, kann nicht wissen, wann das geschieht. Ein LogStop Zustand tritt ein, wenn 5 Sekunden lang kein nennenswerter Motorstrom fliesst, z.B. <=0,1A mit einem JIVE, und der BEC-Strom kleiner/gleich 2,9A ist. Im LogStop wird das Log Recording angehalten, nicht aufgezeichnet. Die Hoffnung ist nun, dass dieser Zustand besteht im Zeitpunkt des Abschaltens nach einem Flug. — LogStop ist keine Garantie, erhöht aber die Chancen, das Dateisystem konsistent zu halten. (Das betrifft natürlich nicht einen JLog im Enabling Status “GW”, der nicht loggt.)

Neben dem LogStop Checkbutton im JLC gibt es einen weiteren, extRPM affecting. Hat man einen JLog-eigenen Drehzahlsensor in Betrieb, kann man damit JLog befehlen, dass er auch dann aus einem LogStop erweckt werden kann, wenn eine ESC-externe Drehzahl anliegt.

Im Bereich der ESC-basierenden Standardalarmschwellen gibt es einen Checkbutton Ubec Dip Detection. Viele Anwender ignorieren ihn, – das sollten sie aber nicht. Es gibt keine individuell einstellbare Alarmschwelle, die man auf Ubec setzen kann. Stattdessen merkt sich JLog die BEC-Spannung beim Start und erkennt einen Dip, der einen Ubec-Alarm auslöst. Ein Dip liegt vor, wenn die aktuelle Spannung Ubec mehr als 0,5V unter die ursprüngliche Spannung fällt und dieser Zustand länger als mindestens 0,4 Sekunden anhält.
Der Dip Alarm wird auf Ubec jeder Quelle angewendet, also auch auf die Ausgangsspannung eines HV²BEC. Wirkungslos könnte das sein, wenn JLog aus dem BEC eines ESC versorgt wird, und dessen Spannung komplett ausfällt, wie z.B., wenn JLog am Diagnostikport (Jumper Port) eines JIVE angeschlossen ist, aber kein Puffer verwendet wird.
Der Checkbutton sollte einfach generell angeklickt sein!
Einige Telemetriesysteme erlauben nicht, dass ein Sensor (JLog) Alarme sendet, Futaba (S.Bus2), SPEKTRUM teilweise, HiTec, FrSky, JR. Mit allen diesen Telemetrien hat sich JLog trotzdem einen “trickhaften Weg” geschaffen, Alarme senden zu können. Anwender von JETI EX müssen dafür sorgen, auf den entsprechenden Alarmcode von JLog, ‘M’, einen passenden Voice File im Terminal (Sender, Profibox) gemappt zu haben, wenn sie nicht, á la Futaba, z.B., das Terminal die Alarme selbst generieren lassen. JLog’s UbecDip Alarm erscheint via jede Telemetrie außer JR, sofern man im jeweiligen Terminal das in Telemetrie beschriebene Setup hinsichtlich von Alarmschwellen vorgenommen hat.

JLog2.6:  Welchen Enabling Status mein JLog hat, kann ich in “version.txt” auf der SD nachschauen, siehe. Sofern CONFIG.txt von der SD in JLC eingelesen wurde, zeigt JLC auch den Enabling Status:

Das ist ab JLC6 so (nur für JLog2.6), ebenso in JLC7. JLC7 ist das aktuelle Major Release, wieder Einer für alle (JLog 2, 2.5, 2.6).

.

Installieren von JLC

JLC ist eine sog. “Click Once Application”, basierend auf .NET. Erforderliche Komponenten im OS sind Microsoft  .NET Framework 4 Client Profile (x86 und x64) und Windows Installer 3.1. Sollten die Komponenten nicht vorhanden sein, werden sie beim ersten Installieren von JLC erst aus dem Netz geholt und installiert.

Zunächst das selbstentpackende Archiv, z.B. JLC7.exe, anklicken (starten), es entstehen die zwei regulären Dateien setup.exe und JLog Configurator 7.application sowie das Directory Application Files.

Das Installieren des JLC geschieht durch Anklicken (starten) von setup.exe!

Aus verschiedenen Gründen könnte es Probleme dabei geben, zwei bekannt gewordene seien genannt:
- Der Pfad des Installationsortes im Dateisystem sollte nicht zu lang sein und er sollte keine Sonderzeichen und möglichst auch keine Leerzeichen enthalten!
- Es kann u.U. passieren, dass Windows die Installation an ungünstiger Stelle abbrach. Danach wird jede weitere Installation verweigert. In so einem Falle sollte man folgendes probieren:
… – Programm deinstallieren (Systemsteuerung->…)
… – Cache leeren: C:\<user>…\AppData\Local\Apps\2.0 .. (die Variante mit dem wahrscheinlichsten Erfolg)
… – Registry putzen (JLC entfernen)

JLC Updates: Das geschieht i.Allg. automatisch: JLC fragt beim Start den Deployment Server (JLog HP) ab und bietet ein Update an, wenn verfügbar. Es ist allerdings so, dass Update Dateien immer nur für das JLC Major Release vorliegen, das die momentane Hauptversion von JLC darstellt, wie z.Z. JLC7.