Der Lieferung von JLog liegt ein Servo-Patchkabel bei, mittels dessen man den “JIVE Port” des JLog mit dem “Diag Port” des JIVE verbindet. “JIVE Port”: Dieser ist bei JLog2.6 und 2.5 in identischer Position und identisch markiert. An JLog2 ist es der Port K5, markiert als “Jive”. Masse liegt immer außen bei JLog.
Der “Diag Port” des JIVE ist der 3-polige Anschluß an der Motorkabelseite des JIVE, wo ein 2-poliger Jumper eingesteckt werden kann, um den JIVE in den Setup Modus zu versetzen.
Zu beachten ist: Startet der JIVE (Powerup) mit eingestecktem Jumper, sendet er keinen Diagnosedatenstrom! Steckt JLog am Port, wertet das der JIVE wie nicht vorhandenen Jumper, sendet Diagnosedaten, die JLog verarbeitet.
Der “JIVE Port” von JLog2.6/2.5 stellt einen der 3 Wege dar, JLog mit Betriebsspannung zu versorgen. Bei JLog2 ist das der einzige Weg. Der JIVE hat an seinem “Diag Port” die momentan eingestellte BEC-Spannung anliegen. Allerdings sollte diese hier mit maximal 100mA belastet werden! Grund ist, dass der JIVE in beiden relevanten Leitungen, Plus und Masse, intern einen PTC (Kaltleiter) verwendet, was der Strombegrenzung dient.
Wenn man JLog via seinen “JIVE Port” aus einer anderen Spannungsquelle versorgen will, sollte man Folgendes bachten:
Der “Diag Port” des JIVE ist im Sinne eines Servoanschlusses atypisch belegt, um einen Kurzschluß der BEC-Spannung durch den 2-poligen Jumper zu vermeiden, sollte der in der falschen Position eingesteckt werden: “Rot” (mittlerer Pin) ist “Signal“, “gelb” ist <+>! Um ein Servo-Patchkabel verwenden zu können (straight-through), ist der “JIVE Port” an JLog identisch belegt.
JLog2 darf nicht mehr als 6V erhalten! (JLog2.6 und 2.5 sind HV-fähig bis mindestens 12V.)
Setup (JLC)
Kommunikation JIVE–JLog
Die Kommunikationsparameter stellen sich automatisch ein. … Allerdings: Relativ selten, aber es kann passieren, dass JLog den JIVE nicht richtig lesen kann. Das äußert sich dann in Irrsinnswerten im Log und in der Telemetrie, in Fehlalarmen natürlich auch. In einem Logfile auf der SD (.txt) sieht man dann meist negative Werte (Vorzeichen “-”), wo keine hingehören. Außerdem springt der Time Stamp (Zeitmarke), der Wert nach “$1;1;” am Anfang jeder Zeile. JLog verwendet als Zeit die Time Stamps im Datenstrom des JIVE, der JIVE ist der Zeitgeber. Springt eine Zeitmarke zurück in der Zeit, äußert sich das in der Interpretation eines Logfiles durch LogView dadurch, dass jedesmal eine neue Log Session eröffnet wird.
Beobachtet man so ein Verhalten, hat man einen “Ausreißer-JIVE” erwischt. Prozessor #2 im JIVE, ein ATmega, der den Diagnosedatenstrom sendet, verwendet keine stabile Taktfrequenz, die mit einem Resonator oder Quartz erzeugt wird. Sein Takt ist gewissermaßen freischwingend, nur durch ein R-C-Glied bestimmt. Dadurch kann es vorkommen, dass dessen Taktfrequenz soweit vom Soll abweicht, – es ist auch temperaturabhängig, – dass die vom Takt abgeleitete Baudrate des seriellen Diagnosedatenstroms so differiert, dass JLog es nicht mehr lesen kann. Es gibt eine Checksumme in jedem Datenpaket vom JIVE. Stimmt diese nicht, ignoriert JLog das Paket. Man sieht das daran, dass dessen grüne LED “stottert”, sie blinkt 1x für jedes empfangene/ausgewertete Datenpaket. Leider ist das Verfahren der Checksumme vom JIVE kein CRC, als Integritätscheck sehr unzuverlässig. Daher kommen genug fehlerhaft gelesene Pakete durch. Dass JLog negative Werte erkennen kann, wo von Hause aus keine vorkommen können, ist daher Absicht, um recht einfach feststellen zu können, ob man es mit einem “Ausreißer-JIVE” zu tun hat.
Abhilfe
JLog verfügt über eine “Baudrate Correction”, einstellbar im Konfigurator JLC, mittels derer er sich an die abweichende serielle Bitfrequenz so eines JIVE anpassen kann:
Ich 99% der Fälle hatte ein Wert von “-2%” es geheilt.
mAh
Die meisten ESCs messen den Motorstrom bzw. den Batteriestrom nicht sehr genau. Die praktische Auflösung ist i.Allg. nicht besser als 1A, also kann man bei geringen mittleren Motorströmen keine hohe Genauigkeit erwarten.
Viel entscheidender ist aber das Meßverfahren und der Punkt im Stromkreis, an dem gemessen wird. Der JIVE ist hier ein Extrem, er misst an einer Stelle, wo es keinen reinen Gleichstrom geben kann, sodass dessen PWM Duty (%) und die veränderliche PWM-Frequenz mit der Conversion Time des A/D-Wandlers im messenden Microcontroller (#1) des JIVE interagieren. Außerdem wird gar nicht der Primärstrom (batterieseitig) gemessen (auch der BEC-Strom ist ein Sekundärstrom). JLog wendet daher ein relativ aufwändiges Verfahren an, den vom JIVE gelieferten Motorstromwert in die Realität umzusetzen, – erfolgreich.
Leider kommt hinzu, dass der JIVE gar keinen echten Shunt zum Messen verwendet, es handelt sich um ein Stück Leiterbahn auf einer der Platinen. Dieser “Shunt” ist nicht nur nicht kalibriert, er hat auch aufgrund des verwendeten Materials einen erheblichen Temperaturkoeffizienten, den JLog nachträglich mit z.V. stehenden Mitteln kompensiert. “Mittel” sind die beiden Temperaturen “tFET” und “tBEC”, die der JIVE als Daten liefert.
Egal, aus welchem Grund Stromwerte abweichen könnten, egal, ob der ESC selbst oder JLog die verbrauchten mAh errechnet (beim JIVE der Fall), der Augenblick der Wahrheit ist die verbrauchte Akkukapazität (mAh) am Ende, – im Vergleich zum nachgeladenen Betrag.
JLog bietet daher grundsätzlich die Möglichkeit für den Anwender, den Motorstrom bzw. mAh zu “kalibrieren”. Das geschieht anhand der praktischen Ergebnisse, einstellbar via Konfigurator JLC:
Es erfolgt einfach +/- in ganzzahligen prozentualen Schritten.
Dabei bitte nicht vergessen: Auch ein Charger ist kein “Messgerät”, außerdem gibt es Lade- und Balancierungsverluste, je höher der Innenwiderstand eines LiPo Packs durch Alterung wurde, umso mehr.
Just-in-Time
Die vom JIVE gelieferten Zeitmarken beginnen erst, zu laufen, wenn der JIVE initialisiert hat. Davor gibt es kein Log Recording durch JLog, weil sich alles auf einen Zeitpunkt “Null” schreiben würde, – LogView würde es nicht auswerten können. Einige Werte sind aber bereits vorher sinnvoll, Ubat, z.B., und werden in die Telemetrie gegeben.
Alle 100ms gibt es vom JIVE einen neuen Datensatz. JLog zeichnet aber auch generell im 10Hz-Takt auf.
Die verbreiteten Theorien, dass man erst bei viel höheren Messraten alles im Log mitbekäme, sind falsch. Im R/C-Betrieb hängt es von ganz anderen Eigenschaften der Messung und der Datenverarbeitung ab, wie es sich hierherum verhält. JIVE-JLog sind die beste Kombination im Markt, um reale Forensik machen zu können. Der Nachteil des JIVE, dass er auf der Motorseite den Strom misst, der “Nachteil”, dass er Messwerte nicht integriert, wird mit Hilfe von JLog zu einem Vorteil, – und dabei spielt es keine Rolle, dass mit “nur” 10Hz gemessen/aufgezeichnet wird.
JIVE’s Daten
Der JIVE liefert folgende Rohdaten in JLog’s Datenerfassung:
Alle anderen Datenwerte, mit denen JLog umgeht, sind davon abgeleitet, sind Alarme, oder es handelt sich um Daten von anderen, von JLog-eigenen Sensoren.
JIVE - Typ und Firmwareversion
JLog funktioniert mit jedem JIVE, unabhängig davon, um welches Modell es sich handelt und welche Firmware auf dem JIVE geflasht ist. (Was den angekündigten “JIVE Pro” betrifft, ist damit zu rechnen, dass er sich an JLog wie ein KOSMIK verhalten wird.)
Ein JIVE sendet sehr viele unterschiedliche Daten in seinem Diagnosedatenstrom, bis zur Firmwareversion 7 waren es 131, ab v9 ca. 10 weniger. Einige Daten sind redundant, einige werden auch in nicht mit jedem Datenpaket geliefert. Das liegt daran, dass das Protokoll nicht für Logging-Zwecke geschaffen wurde, es orientiert sich an Variablen in der Firmware des JIVE.
JIVEinfo.txt
JLog schreibt zwei dieser zusätzlichen Datenwerte in eine Datei “JIVEinfo.txt” auf der SD. Er gewinnt die Daten in einer Boot Session mit einem JIVE, merkt sie sich (im EEPROM seines Prozessors) und schreibt sie bei seinem nächsten Start in die Datei. Die Datei enthält eine Zeile mit zwei Werten:
Erster Wert: Firmwareversion des JIVE.
Zweiter Wert: Gesamtlaufzeit des JIVE in Sekunden. Ab v9 steht hier “N.A.”, nicht verfügbar.
Ab v9 wird die Gesamtlaufzeit nicht mehr geliefert durch den JIVE.
Firmwareversion 9 sollte Bugs bereinigen, die u.a. dazu führen konnten, dass der JIVE mitten im Hochlauf plötzlich schlagartig abschaltete, alles aus. Ein Teil dieses Bugs blieb offenbar erhalten. Anwendern passiert es immer noch, dass ein JIVE plötzlich nur noch mit konstant ca. 200 rpm kommutiert. Ein Reset des JIVE wird erforderlich. Die Ursachen solcher Erscheinungen liegen in der Art der Interkommunikation der beiden Prozessoren im JIVE, die sich unkoordiniert gegenseitig in den Speicher greifen, EEPROM. Ich würde das als “unseriöses Design” bezeichnen. Wie dem auch sei, so ein Designbug ist nicht mehr vollständig heilbar, ohne die Hardware zu ändern. Im Rahmen des Bugfixing der v9 fiel der Transfer einiger Daten zwischen den Prozessoren weg, um dadurch offenbar die Wahrscheinlichkeit von Kollisionen zu vermindern. Dabei blieb auch der Betriebssekundenzähler auf der Strecke. Infolgedessen schreibt JLog ab v9 “N.A.” statt der Betriebssekunden an die Stelle des zweiten Wertes in JIVEinfo.txt.
Firmwareversion in JIVEinfo.txt: Bis v9 stimmte diese. In v10 vergaß Kontronik, die Version zu erhöhen, es kam immer noch “9″. Warum auch immer, ob man einen Fehler nicht zugeben wollte, ob man einen “Kult” draus machte: Das Problem bleibt auch ab v11 erhalten, V11 liefert “10″, v12 liefert “11″, und die momentan aktuelle v13 liefert “12″. Die JLog-Entwicklung wartete lange ab, auf Fragen an Kontronik gab es keine klaren Antworten. Daher korrigiert JLog das mit seinen neuesten Firmwareversionen (z.Z. zumindest für JLog2.6) nun selbst: Bis JIVE v7 stimmt es. Ist der JIVE v10, liefert er ja “9″ wie aus v9, JLog kann nicht entscheiden, ob v9 oder v10, schreibt auch “9″. Man also nicht anhand JIVEinfo.txt feststellen, ob man v9 oder v10 vor sich hat. Ab JIVE v11, JIVE liefert “10″, korrigiert JLog selbst “+1″, sodass es in JIVEinfo.txt nun wieder stimmt, – solange Kontronik nicht einen plötzlichen Sinneswandel erleidet.
Der Lieferung von JLog liegt ein Servo-Patchkabel bei, mittels dessen man den “JIVE Port” des JLog mit dem “Diag Port” des JIVE verbindet. “JIVE Port”: Dieser ist bei JLog2.6 und 2.5 in identischer Position und identisch markiert. An JLog2 ist es der Port K5, markiert als “Jive”. Masse liegt immer außen bei JLog.
