Jeti kurzer Signalverlust DC 16 und in Datenanalyse kurz falsches Modell gewählt

[machsig]

Hallo zusammen,
Ich hatte gerade folgendes Phänomen:
Habe 3 Flüge à 8min ohne Probleme mit meiner Votec gemacht. Beim 4ten Flug hatte ich dann für kurze Zeit keine Kontrolle mehr, dann hatte ich sie wieder und bin gelandet.
Die Datenanalyse zeigt aber was ganz komisches an. Genau zu dem Zeitpunkt, als das Problem auftrat, ist ein Pfeil zu sehen, der "F4U Corsair" zeigt. Das Modell hatte ich auf einem anderen Empfänger einprogrammiert, aber letzte Woche aus dem Sender gelöscht. Es existiert auch nicht mehr und ich habe definitiv den richtigen Log ausgewählt.
Hat jemand eine Erklärung?
Der Sender lag heute tagsüber im Senderkoffer im Auto ohne direkte Sonneneinstrahlung. Sender lag auch nicht in der Sonne und war kühl bei Verwendung. Die Software Version ist die 5.06 vom 26.05.2021 - aber seitdem habe ich keine Probleme damit gehabt.

Vielen Dank für die Antworten!
Gruß
Max

 

[Pulsar07]

Könntest du mal den Log-File des Fluges hier einstellen?

 

[machsig]

Hier die Datei: Die ".txt" muss in ".log" umbenannt werden, sonst konnte ich es nicht hochladen.
Bei ca. 6min 31s tritt der beschriebene Fehler auf.

Den Fehler konnte ich später nochmal nachstellen. Dabei hatte ich meine Piper gebunden, um am Boden zu testen. Hatte den Flieger ca. 24min laufen und habe nur die Ruder bewegt und ab und zu den Motor laufen lassen. Ab ca. 9min bis 10min12s habe ich einen Reichweitentest gemacht - den sieht man im Log. Bei Minute 20 kommt dann die Meldung "Votec 332", bei 20min27s die Meldung "Ju-87 Stuka" und bei Minute 21,07 dann nochmal "Votec 332". Ob bei den Alarmen ein Ausfall war kann ich nicht genau sagen. Ich saß auf einem Stuhl am Platz und habe dann irgendwann dem Flugbetrieb zugeschaut. Die Log der Piper hänge ich auch an.

 

[-mhr-]

Was ist für ein Empfänger verbaut? Den schon mal getauscht?

 

[smartrobert]

Warum nicht das hier (KLICK) machen? Und wenn es nicht funktioniert dann zum Service schicken - wer weiß denn schon, was sich im Hintergrund noch so alles abspielt?

Gruß Robert

 

[nichtgedacht]

Moin,

was mir auffällt:

In beiden Dateien passen die Timestamps der Messages nicht.
Die Timestamps werden ja aus einer Variablen erzeugt in der die Zeit steht die die MCU seit dem Einschalten läuft.
Da bei den Messages erst zu kleine Werte kommen die ja scheinbar später geschrieben wurden, deutet das auf ein beschädigtes Filesystem der Speicherkarte hin. D.h. Teile könnten zu einer anderen Datei gehören.

Wenn der Sender wirklich die Einträge in dieser Reihenfolge geschrieben hat ist er kaputt.

Die letzten beiden Telemetrieeinträge sind jeweils mit Q=0%
Wurde da der Empfänger ausgeschaltet während die Aufzeichnung noch lief?

Wie schaltest Du eigentlich die Aufzeichnung ein/aus?

Wie erklärst Du Dir selber "Reichweitentest"?
Hast Du selber Messages eingerichtet mit LUA?

Das angehängte Perl Script dekodiert die einzelnen Einträge:

"cat xxx.log | JetiLogAnalyzer.pl"

Gruß Dieter

 

[Manuel_K]

Hallo,
das ganze schaut schon schwer nach einem Problem mit der SD Karte aus. Diese würde ich erstezen, idealerweise gleich eine Class10 o.ä. dann läuft der Sender auch einiges geschmeidiger.
Auf die Übertragungssicherheit/Verbindung hat das alles keinen Einfluss, hier muss man sich keine Sorgen machen.
Gruß Manuel

 

[PeGru]

" .... hatte ich dann für kurze Zeit keine Kontrolle mehr ...."

Auf die Übertragungssicherheit/Verbindung hat das alles keinen Einfluss

 

[machsig]

Was ist für ein Empfänger verbaut? Den schon mal getauscht?

Soweit ich mich gerade erinnere ein R8, aber habe es wie beschrieben mit zwei unterschiedlichen Modellen unabhängig voneinander nachstellen können.

 

[machsig]

Warum nicht das hier (KLICK) machen? Und wenn es nicht funktioniert dann zum Service schicken - wer weiß denn schon, was sich im Hintergrund noch so alles abspielt?

Gruß Robert

Das werde ich mal morgen ausprobieren. Hacker bzw. Jeti ist auch schon eingeschaltet.

 

[machsig]

Moin,

was mir auffällt:

In beiden Dateien passen die Timestamps der Messages nicht.
Die Timestamps werden ja aus einer Variablen erzeugt in der die Zeit steht die die MCU seit dem Einschalten läuft.
Da bei den Messages erst zu kleine Werte kommen die ja scheinbar später geschrieben wurden, deutet das auf ein beschädigtes Filesystem der Speicherkarte hin. D.h. Teile könnten zu einer anderen Datei gehören.

Wenn der Sender wirklich die Einträge in dieser Reihenfolge geschrieben hat ist er kaputt.

Die letzten beiden Telemetrieeinträge sind jeweils mit Q=0%
Wurde da der Empfänger ausgeschaltet während die Aufzeichnung noch lief?

Wie schaltest Du eigentlich die Aufzeichnung ein/aus?

Wie erklärst Du Dir selber "Reichweitentest"?
Hast Du selber Messages eingerichtet mit LUA?

Das angehängte Perl Script dekodiert die einzelnen Einträge:

"cat xxx.log | JetiLogAnalyzer.pl"

Gruß Dieter

Vielen Dank für die umfangreiche Antwort!
Ja, meine Aufzeichnung läuft immer, darüber habe ich mir auch ehrlich gesagt noch nie Gedanken gemacht. Gestoppt wird die Aufnahme bei Ausschalten des Senders - also ja, Aufzeichnung lief und Empfänger war dann aus.
Den Reichweitentest habe ich dann selber durchgeführt und dort hat es automatisch die Messages gesetzt.
Ich denke ich werde im ersten Zug die SD Karte ersetzen und testen.

 

[hnagl]

Du hast ein defektes Bec. Sonst nichts. Wenn der R8 die neueste Firmware hätte, wäre Neustart des Empfängers als
Fehlermeldung gekommen. Dein Bec hat kurze Aussetzter, darum das Dreieck als Fehlermeldung.
Wäre die Modelldatei oder das Logfile defekt, könntest du den Sender nicht ausschalten, weil dieser das File nicht auf die SD Karte schreiben kann. Wenn du den Empfänger nacheinander an verschiedenen Modelldateien bindest, darfst du dich nicht wundern, das bei den Fehlermeldungen andere Modelldateien erscheinen.
Der Sender findet die Kennung des Empfängers eben in den anderen Modelldateien wieder.
Gruß Harald

 

[nichtgedacht]

Das ist jetzt aber eine selbstbewusste Behauptung mit dem BEC. Da müsste ja mitten im Flug mindestens der "Q" Wert runter gegangen sein während die Timestamps ungefähr in gleichen Abständen folgen.

Ich habe es eben mal ausprobiert und die Stromversorgung am Empfänger kurz unterbrochen während einer Aufzeichnung.
Der "Q" Wert ist kurz auf 0 aber ein Alarm "Neustart des Empfängers" kommt nicht. Erst wenn diese verdammte Verzögerung für Alarm "Telemetrieverlust" auch erreicht wird kommt auch "Neustart des Empfängers".

Offenbar lässt bei Max nur eine Stoppuhr die Aufzeichnung loslaufen.
Er stoppt dann die Aufzeichnungen nicht explizit sondern schaltet nur manchmal den Sender aus.

Wie ist dann erklärbar, dass:

1. Im Flug der "Q" Wert immer ok ist?
2. Der kleinere Timestamp 000392522 nach dem Flug in der gleichen Datei auftaucht?
3. Der Timestamp 000460120 wiederum unmittelbar danach kommt?

Für 2. müsste die MCU im Sender zwischendurch noch mal neu losgelaufen sein. Für 3. müsste die Aufzeichnung mindesten unterbrochen worden sein. Wie landet das dann in der gleichen Datei? Mit Beginn einer neuen Aufzeichnung sollte auch eine neue Datei erzeugt werden.
Unter welchen Umständen gibt es überhaupt eine Message mit "Modellname"? "Modellname" taucht normalerweise nur am Beginn einer Aufzeichnung als Kommentar auf, oder?

@max
Wie wird die Stoppuhr eingeschaltet?

Auf jeden Fall ist es keine gute Idee die Aufzeichnung nicht explizit zu Start/Stoppen.

Gruß
Dieter

 

[hnagl]

Es genauso wie ich geschrieben habe, siehe Foto. Die Neustartmeldung kommt nach 0.5s Ausschalt und Ansteckzeit, auch der falsche Name ist bei mir genauso, habe einen neuen Rex9 Slimeline an einer bestehenden Modelldatei "Needle" getestet. Ich habe den Strom zweimal kurz abgeschaltet und wieder ein.

 

[nichtgedacht]

Für die Leute die kein Perl zur Hand haben:

 

[hnagl]

Ist die Ansteckzeit kürzer als die 0.5s, so ist noch genug Strom im Empfänger vorhanden , sodass er nicht neu bootet.

 

[nichtgedacht]

Es genauso wie ich geschrieben habe, siehe Foto. Die Neustartmeldung kommt nach 0.5s Ausschalt und Ansteckzeit, auch der falsche Name ist bei mir genauso, habe einen neuen Rex9 Slimeline an einer bestehenden Modelldatei "Needle" getestet. Ich habe den Strom zweimal kurz abgeschaltet und wieder ein

Zeig' doch mal die Datei.
Das ergibt aber auch keine Antworten für das Problem hier.

 

[AndreCH]

Da könnte man ja mal einen Kondensator an den Empfänger anstöpseln, und der Fehler müsste ausbleiben

 

[machsig]

Also ich habe wie beschrieben den Fehler an zwei verschiedenen Modellen mit zwei verschiedenen Empfängern gehabt. Dass bei beiden plötzlich das BEC defekt ist, halte ich für unwahrscheinlich. Ich versuche probiere morgen mal einiges aus und auch Verbrennermodelle ohne BEC.

 

[klemm53]

mich wundert, dass die Logs ordentlich aussehen bis auf die jeweils letzten 8 bzw 11 Zeilen. Dort will der Sender noch Daten loswerden, die zu keinem Sensor passen (Sensor ID ist in den Zeilen null). Es könnten also auch die Modell Dateien defekt sein, was zu SD Karten Problem passen würde.
Max, lade bitte die betreffenden beiden Modell Dateien hier mal hoch, damit man sich das ansehen kann

Grüsse
Klaus