J-Log.eu - Forum

Arne, ich muss mich heute früher verziehen, weil es morgen ziemlich früh zum Kunden geht. Den Tag über bin ich also unterwegs. Daher poste ich hier mal meine Antwort, bevor Du die Frage stellst , - ich hoffe, das passt:

Siehe http://jlog.hacknet.eu/jlog2/faq/seltene-probleme-kommunikation-jive-jlog

Der JIVE sendet seine binären Diagnostikdaten asynchron-seriell.
Im JIVE gibt es zwei Prozessoren (Microcontroller), einen DSP, der die Hauptfunktion, Kommutierung und Drehzahlregeleung, macht, einen zweiten, der im Wesentlichen periphere Funktion hat. Letzterer sendet die Daten.

Die Bitfrequenz (Baudrate) in einem seriellen Protokoll wird durch die Software und Hardware eines Microcontrollers immer von dessen Taktfrequenz abgeleitet. Man ist also davon abhängig, dass diese bekannt ist, ergo halbwegs genau eingehalten wird. Daher nimmt man als schwingungserzeugendes Element normalerweise einen Quarz oder einen Resonator. Hier aber hat der Designer des JIVE, aus welchen Gründen auch immer (Technischer Gutglaube, Cent-Fuchserei?), sich entschieden, den Taktgenerator quasi frei schwingen zu lassen, frequenzbestimmendes Element ist ein RC-Glied, ein Widerstand und ein Kondensator.

Nun scheinen diese Bauelemente exemplarbedingt einer zu hohen Toleranz unterworfen sein zu können, einen TK haben sie auch, evtl. spielt auch Alterung eine Rolle.
Weicht nun die Taktfrequnez des Prozessors über ein bestimmtes Maß ab, dann kann das auch die Baudrate der seriellen Aussendung tun, in dem Maße, dass der Empfänger (JLog) teilweise Bahnhof versteht. Es gibt zwar ein CRC (Cyclic Redundancy Check) im binären Datenpaket, das ist aber dergestalt, dass gerade mal 1-Bit-Fehler erkannt werden können. JLog wertet das CRC aus, verwirft schlechte Pakete, richtig versaute Inhalte sind aber nicht erkennbar, gehen somit in die Auswertung, und damit in die Aufzeichnung, die State Machine, das Alarming und die Telemetrie.

Nun, den betreffenden JIVE können wir nicht ändern, nicht mal Kontronik könnte das, sie müssten ihn ja aufschnitzen dazu.
Wir (JLog) können uns aber anpassen. Dazu gibt es im Konfigurator JLC unter der "Abdeckung" "Emergency" eine "Baudrate Correction". Im Allgemeinen reicht es aus, mal mit plus oder minus 3 Punkten zu beginnen, bisher (vielleicht 10..15 Fälle, alle werden mir ja nicht bekannt) waren es meist -2 bis -3 Punkte, die es dann heilten.

Zum Testen einfach nur den JIVE besaften und ihn initialisieren lassen, weil erst dann die Timestamps befüllt werden. (Wir nehmen die (relative) Zeit aus den Daten des JIVE, für den startet die aber erst nach Initialisierung. Ohne Zeit hat es für uns keinen Sinn, auszuwerten und aufzuzeichnen, jedenfalls machte es für viele Daten-Items keinen Sinn.) Dann mal einen Augbenblick laufen lassen. Dann AUS, die SD nehmen und direkt in den Logfile (.txt) gucken.
Mißverstehen des Datenprotokolls führt meist auch stochastisch zu negativen Werten im Log, negative Werte haben hier nichts zu suchen. Dann mal ganz links in jeder Zeile nach dem Fortschritt der JIVE-Zeit gucken. Es darf keinen zeitlichen Rückschritt oder sonstige Ausreißer geben.
So kann man sich mittels der "Baudrate Correction" relativ schnell an den richtigen Korrekturfaktor herantasten.
Einlesen in LogView ist dann der letzte und härteste Prüfstein. Es muss sich um EINE Log-Session handeln (Rückschritte im Verlauf der Timestamps lassen LV eine neue Session kreieren.), die automatische Bereichswahl der Achsen darf uns nicht geärgert haben (durch Ausreißerwerte), negative Achswerte sind ein Nogo.

----
Asynchron-serielle Datenübertragung:
Nach der Flanke des Startbits bis zum Erkennen des ersten Stopbits, läuft das Ganze unsynchronisiert zwischen Sender und Empfänger. Weichen die Frequenzen zu weit voneinander ab, dann greift die Bit-Abtastung des Empfängers sozusagen in's Klo.
(Zum Bild: Unser Pegel ist aber sog. "TTL-Pegel", 0..2V, ca. 3V im Allg. und auch hier.)
http://commons.wikimedia.org/wiki/File:RS-232_timing.png
(Ist blöderweise ein PNG, kann man nicht einbetten hier.)

_________________
Tom

Hallo Tom!

Klar, das verstehe ich - ich hatte ja heute (Dienstag) auch einen arbeitsreichenTag, weswegen ich mich auch nicht früher wieder um mein "Problem" kümmern konnte und entsprechend hier nicht aktiv geworden war.
Um so mehr war ich super überrascht, daß ich von Dir schon eine fertige Verdachts-Analyse vorfand, als ich mich ins Forum eingeloggt hatte!
Und - was soll ich sagen - Du liegst goldrichtig und hast mir vor allem absolut verständlich und logisch erklärt, was los ist und vor allem, was ich dagegen wo tun kann!!! Das war ja eine wesentliche Schwierigkeit, daß ich nicht gefunden habe, wo ich die Baudrate verändern kann... Jetzt im Nachhinein ist natürlich klar, was >emergency< zu bedeuten hat. Nur manchmal ist man eben auch betriebsblind!
Also vielen Dank für Deine absolut fundierte, kurzwegige und schnelle Hilfestellung!!! Das JLog2 loggt jetzt den Problem-Jive mit einer um -2 korrigierten Baudrate auf Anhieb korrekt!

Aber eines ist für mich persönlich mal wieder kaum zu glauben: Ich kaufe mir endlich mal ein JLog und schließe es auf Anhieb genau an einen Jive an, der Probleme macht - dabei hätte ich auch auch noch mehrere andere in anderen Helis gehabt... Mc. Murphys Gesetz wohl!

Gruß, Arne (Güldi)

Supi.

_________________
Tom