J-Log.eu - Forum

Ihr verwirrt mich, weil Ihr jetzt im Doppelpack auftretet..

Logs am Ende der Telemetrie sind nicht gut geeignet, denn die Werte, die in eine Telemetrie gehen, sind für Displays und Menschen "geschönt", auch ist das Zeitraster gröber, - teilweise unterliegen die übertragenen Daten keinem Integritätcheck, bei SPEKTRUM, z.B.

Außerdem, - Jungs, bitte nicht mißverstehen:
Ein paar Leute heulten rum, der JLog wäre doch so viel teurer als TelMe, - und zwar ungeachtet dessen, dass es das TelMe ja gar nicht zu kaufen gibt, nur unseriöserweise seit teilweise >2J als Ghost in den Shops platziert.

Wir halbierten den Preis, indem wir den "GW" brachten. Ergebnis: Es wird fast kein Enabler für Logging gekauft, wir zahlen je JLog2.6 ca. $6 drauf. -- Dann soll ich mich noch mit den Viewern dieser unsinnigen Log Recorder in den Sendern rumschlagen? Nö, irgendwo hört's auf mit Heilsarmee.

----------------------------------------------

Habe jetzt verstanden, was Du meinst.
Hintergrund: LogView versteht viele Records (Zeilen) nicht, weil das Aufzeichnungsformat fehlerhaft ist.
So langsam falle ich vom Glauben ab, was K betrifft.

Das ist falsch, der jeweilige Record mit Kommentar wird nicht gewertet. Es führt außerdem zu Verschiebungen auf der Zeitachse von LogView!



Die C-Syntax "//" ist nutzlos, wichtig ist ein White Space zwischen dem letzten Item (ungenutzte Checksumme) und weiteren Zeichen (Kommentar):



Bringt man das i.O., siehts dann anders aus. Dieser Einfriereffekt ist dann weg.

Flug1: Das mag wirklich ein gewollter Motorstop gewesen sein:



Flug2, Event 1: Hier habe ich angesichts der nur 5 Sekunden so meine Zweifel, dass das gewollt war:



Flug2, Event 2: Dito. Allerdings reagiert hier gleich noch der ESC komisch laut seinem Log:



KOSMIK:


LogView (nachdem man das Logformat korrigierte):



Die Fragen sind nun:

1. Was führt dazu, dass der ESC so urplötzlich und offensichtlich ungesteuert einen Gas-Nullimpuls bzw. falschen Gasimpuls bekommt? Vermutlich hat der FBL Controller Hazards beim Umsetzen des Summensignals.

2. Wieso kann der ESC so gefährlich regieren, dass ein kurzzeitiges (nur 20ms) Einbrechen des Gaswertes ihn in einen Status bringt, den er selbst "Standby" nennt, nachdem er, nach einer Wartezeit, selbstständig wieder hoch läuft, - nachdem er zuvor zwar nicht aufhörte, zu kommutieren, aber auf eine Minimaldrehzahl reduzierte?
Auf Bailout Gas erkennt er jedenfalls nicht, denn "TXpwm" hat denselben Wert wie "TX" (Gas).

_________________
Tom

Ich glaube, wir verwenden unterschiedliche Software zur Visualisierung und Interpretation der Daten. Anders kann ich mir die Unterschiede der Darstellung nicht erklären. Sobald ich wieder im Lande bin, werde ich Grafiken und Tabellen aus den Kontroiik-Files aus unserer Software (Data-Explorer) übermitteln. Ich bin auf Kurzurlaub und habe hier leider keime Möglichkeit einen PC zu verwenden.

OK, mach' erst mal Urlaub!

Bitte aber das als Roadmap: Hier geht es um Forensik, daher:

1. Die beste Quelle ist das Log des ESC selbst, was wir zum Glück haben. Logs des Senders außen vor, - das ist Interpretation der Interpretation.

2. Die beiden Logs liegen im Openformat vor. Das ist eine Erfindung des Urknalls LogView, Winfried hat es mit Data Explorer reimplementiert auf Java-Basis.

3. Die Formatfehler, die die Firmware des KOSMIK in das Log baut, werden den Data Explorer beim Lesen/Interpretieren wahscheinlich genauso tangieren. Folgen davon sind a) Interpretationslöcher, b) Verschiebung der Daten auf dem Zeitstrahl!

Anbei die beiden korrigierten Log Files, Space zwischen Zeilen (Record) Ende und Kommentar. Bitte nur die benutzen!

_________________
Tom

Lieber Tom !

Ich übersende eine Grafik, die mit LogView (bisher haben wir den Data Explorer verwendet) erstellt wurde. Sieht für meine Begriffe im relevanten Zeitabschnitt unauffällig aus. Was denkst Du ?

Na ja.. Fragt sich nur, wer für ca. 2 Sekunden das Gas abdreht..

_________________
Tom

Hallo Tom,

wir sind uns mittlerweile ziemlich sicher, dass der Motor nur kurz abgedreht wurde, um die Kontroll-LED des Flybarless-Systems besser sehen zu können und um zu kontrollieren, ob diese wieder rot blinkt (macht sie nämlich bei irgendwelchen Fehlern - sie hat auch im Flug zuvor geblinkt). So gesehen wäre der kurze Absteller, der gar nicht zum vollständigen Stillstand des Rotors führte, wirklich gewollt gewesen. Uns ist jedenfalls keine Drehzahlreduktion im Flug aufgefallen.

Wir haben Deiner Anregung folgend die Änderungen an der Stromversorgung und Masseleitung vorgenommen und mittlerweile auch schon vorsichtige Schwebeflüge allerdings mit kurzen heftigen Pitchstößen vorgenommen (bis 150 Ampere Stromaufnahme !!!). Es haben sich bis dato keine Fehler mehr gezeigt. Vielleicht war das wirklich die Lösung unseres Problems.

Jedenfalls vielen, vielen Dank - wir werden auch weiter berichten. Hoffentlich weiterhin Positives.

lG

Franz

Hmm, ok.. Ehrlich gesagt, fiel es mir in diesem Fall etwas schwer, den roten Faden für die Forensik zu finden, - der wurde mir immer wieder abgeschnitten.

_________________
Tom

Hallo Tom,

Wir haben weiter getestet und sind zur Erkenntnis gekommen, dass das Problem eindeutig am Jlog liegt.

Trotz der anderen Verkabelung kam es wieder zu Resets des FBL.

Wenn man das Jlog abhängt, funktioniert alles ganz normal.

Ich werde jetzt wohl notgedrungen zum Telme greifen müssen.

Kann man in so einem Fall das Jlog beim Händler zurückgeben?

Das erinnert mich an die Logik ehemaliger Nachbarn in Berlin: "Immer wenn Du funkst, spinnt unser TV, also hör auf." Der Schirm eines Koaxkabels zw. Recoder und TV war ab.

JLog hat KEINE Möglichkeit, auf systematischem Wege hier ein Problem zu verursachen.
Die Ursache muss im elektrischen Weg gesucht werden.

Was die Rückgabe betrifft: Das musst Du mit Deinem Händler klären.

Das Ganze macht mich sauer.

_________________
Tom

Wenn Du uns sagst, was wir noch probieren sollen, machen wir das gerne.

Fakt ist, dass das FBL im Jlog Betrieb im Flug (!) neu startet und ohne Jlog alles problemlos funktioniert....