JetiLogAnalytics, eine kleine Software zum Auswerten von Flugmodelldaten

[Pulsar07]

Der Winter ist lang, das Wetter ist schlecht und man soll möglichst Kontakte vermeiden. Was macht man denn dann?
Na Winterprojekte angehen und/oder Software schreiben ;-)

Habe vor ca. 1 Jahr ein kleines Tool geschrieben, mit dem man die Log-Dateien von JETI-Sendern auswerten kann.
Das Tool war ein reines Kommandozeilentool.
Da der Winter lang und doch so mancher regnerischer Tag nicht zum Fliegen getaugt hat, habe ich eine kleine graphische Oberfläche dazu gestrickt, die einem erlaubt das Verzeichnis der Logdateien auszuwählen, den Auswerte-Zeitraum einzuschränken und ein paar Filter für die Ergebnisdaten zu aktivieren.

Das Tool ist in Java geschrieben und das Projekt ist als OpenSource und unter https://github.com/Pulsar07/JetiLogAnalytics verfügbar.
Dort ist auch immer die aktuelle Version auch als gebauter "Ŕunnable JAR"-File verfügbar.
Es wird mindestens ein JRE mit Version 8/1.8 benötigt. Tests mit 'Oracle Java 8' auf Windows 10 und 'OpenJDK 8´ (java-1.8.0-openjdk + java-1.8.0-openjdk-openjfx) auf Fedora 30/31 waren erfolgreich.

Unter Windows und Mac sollte dieser JetiLogAnalytics.jar - File einfach durch Doppelklick startbar sein. Unter Linux muss das Wrapper-Script JetiLogAnalytics.sh zum Starten der Applikation benutzt werden.
Achtung: Einzelne Dateien auf GitHub zu downloaden ist sehr kompliziert. Wenn nur der "Runnable Jar" und das Wrapper-Script benötigt werden (sind im bin-Verzeichnis), ist es am einfachsten auf der Projektseite, den grünen Download-Button zu nutzen, "Download ZIP" auswählen und die beiden Dateien aus dem bin-Verzeichnis des ZIP-Archives zu entpacken.

Finde das Tool sehr nützlich, da man ganz leicht die Flug-Daten aller seiner Modelle, und Flüge aufgelistet bekommt. Man kann ganz leicht, sich z.B. alle Daten von 2019 ausgeben zu lassen. Man sollte lediglich alle Log-Dateien des JETI-Senders in einem Verzeichnis auf einem Rechner gespeichert haben.
Der Clou ist eine Flugerkennung, bei der versucht wird, aufgrund der Signalstärke der Antennenwerte A1 und A2, zu erkennen wann das Modell nicht am Boden oder auf der Werkbank ist, so dass man die "Netto-Flug-Daten" der JETI Logfiles bekommt, ohne Daten und Alarme zu sehen, die irrelevant sind. Der Algorithmus funktioniert sehr gut, so dass Daten, wenn sich das Modell in der Nähe des Senders befindet, nicht in die Auswertung kommen.

Vielleicht ist es ja auch für andere JETI-Nutzer nützlich.

Mehr Infos sind GitHub (https://github.com/Pulsar07/JetiLogAnalytics) oder in deutscher Sprache unter http://www.so-fa.de/nh/JetiLogAnalytics zu bekommen.

Viel Spaß beim Daten auswerten
Gruß Rainer

Hier ein Beispiel eines Scan-Laufs und ein Screenshot der Anwendung:

Lese Log-Dateien:
    scanne Log-Datei: 20200309/14-59-15.log : Modell: X-Swift 3.2       Anzahl Flüge: 1

Modell Statistik (1 Modelle):
Modell                          : X-Swift 3.2
  Anzahl Flüge                  : 1
  Logzeit gesamt                : 00:53:27 (h:m:s)
  Flugzeit gesamt               : 00:43:19 (h:m:s)
  Flugzeit-Ø                    : 00:53:27 (h:m:s)
  Einzelflug (min/max)          : 00:43:19/00:43:19
  Höhe (min/max)                : -3/250 (in m)
  GPS-Speed (min/max)           : 0/234 (in km/h)
  Sig.Impulsabstand (max)       : 53 (in ms)
  Entfernung (max)              : 938 (in m)
  Rx Spannung (min)             : 7.32 (in V)
  Alarme:
    900MHz Tx aktiviert         : 2
    Schw. Signal: Q             : 3
  Sensoren                      : [Rx REX10A, RxB , Tx, VarioGPS]
  Flüge / Details               
    Flug / Zeitstempel              : 2020-03-09 15:01:27
      Log-Datei                     : 20200309/14-59-15.log
      Logzeit gesamt                : 00:53:27
      Flugzeit                      : 00:43:19
      Höhe (min/max/Ø)              : -3/250/148 (in m)
      GPS-Speed (min/max/Ø)         : 0/234/48 (in km/h)
      Sig.Impulsabstand (max)       : 53 (in ms)
      Entfernung (max/Ø)            : 938/363 (in m)
      Rx Spannung (min)             : 7.32 (in V)
      Alarme:
        900MHz Tx aktiviert         : 2
        Schw. Signal: Q             : 3


Gesamtstatistik                 
  time range (days)             : 2
  Anzahl Logdateien gesamt      : 1
  Logzeit gesamt                : 00:53:27 (h:m:s)
  Anzahl Modelle                : 1
  Anzahl Flüge gesamt           : 1
  Flugzeit gesamt               : 00:43:19 (h:m:s)
  Flugzeit-Ø                    : 00:43:19 (h:m:s)
  Flugzeit pro Tag-Ø            : 00:21:39 (h:m:s)
  Flugzeit pro Woche-Ø          : 02:31:36 (h:m:s)
  Flugzeit pro Monat-Ø          : 10:49:45 (h:m:s)
  Flugzeit pro Jahr-Ø           : 131:45:17 (h:m:s)
  Alarme                        :
    900MHz Tx aktiviert         : 2
    Schw. Signal: Q             : 3

 

[onki]

Hallo Namensvetter,

schicke Sache. Ich nutze seither das Auswerteprogramm von Geni, um am Jahresende eine Art Bilanz zu ziehen.
Das hilft mir auch bei der Entscheidung, welches Modell ggf. auf die Abschussliste kommt und wo ein Backup her muss.

Das ist aber alles relativ kompliziert und für nicht PC-affine User eher nicht umsetzbar. Und es gibt viele Anwender, die am PC nicht so geübt sind.
Ich bin im Verein so eine Art Jeti Dr. Sommer. Viele Fragen mich wie was geht und dabei kommt es auch immer wieder zu solchen Fragen, wie man die Modell-Gesamt-Betriebszeit einfach ablesen kann oder die gesamte Motorlaufzeit.

Jeti loggt da eine Kleinigkeit mit, das reicht aber für realle Aussagen bei weitem nicht.

Meiner Ansicht nach wäre eine LUA-Lösung hier zielführender. Also ein Skript, das bei jedem Modell aktiviert werden muss (es gibt AFAIK ja keine globalen LUA-Skripte).
Hier könnte man dann festlegen, welche Timerwerte langfristig aufsummiert werden und welche nicht. Diese Werte würden dann in eine zentrale Datei geschrieben, die alle Modellspeicher beinhaltet.
Idealerweise könnte man diese Datei am Sender aufrufen und z.B. ablesen, wie lange mein Motor bei Modell 4 insgesamt gelaufen ist.
Als Sahnehäubchen wären noch Schwellen eintragbar um z.B. auf einen Serviceintervall beim Getriebemotor (reinigen und neu schmieren) hinzuweisen.

Aber als nicht-Programmierer wird das nur ein Traum bleiben.

Gruß
Onki

 

[Smart]

Der Winter ist lang, das Wetter ist schlecht und man soll möglichst Kontakte vermeiden. Was macht man denn dann?
Na Winterprojekte angehen und/oder Software schreiben ;-)


Vielleicht ist es ja auch für andere JETI-Nutzer nützlich.

Mehr Infos sind GitHub (https://github.com/Pulsar07/JetiLogAnalytics) oder in deutscher Sprache unter http://www.so-fa.de/nh/JetiLogAnalytics zu bekommen.

Viel Spaß beim Daten auswerten
Gruß Rainer

Hallo Rainer (Pulsar07),

habe dein Tool am Wocheende ausprobiert, finde ich sehr nützlich und die Werte (Anzahl Flüge, Dauer, etc) scheint plausibel.
Ein kleines Problem scheint es allerdings bei der Ermittlung der Höhenwerte zu geben.

Beispiel:
Bei einem Flug gibt Log Analytics diese Werte aus:
Flug / Zeitstempel : 2022-08-23 16:52:27
Log-Datei : 20220823\16-52-16.log
Logzeit gesamt : 00:35:55
Flugzeit : 00:35:01
Höhe (min/max/Ø) : -74/93/0 (in m)
Rx Spannung (min) : 6.96 (in V)
Alarme:
Alarm: Hoehe > 100.0m : 9
Alarm: Hoehe > 150.0m : 10
Alarm: Hoehe > 200.0m : 12
Alarm: Hoehe > 250.0m : 7
Alarm: Hoehe > 300.0m : 8
Alarm: Hoehe > 350.0m : 5
Alarm: Hoehe > 400.0m : 2

Lt den korrekten Alarmen gab es beim Flug Höhen von > 400m.
Die Angabe des Tools für Höhe (min(max/durchschnitt) ist allerdings -74/93/0.
Falls du noch an dem Tool arbeitest, habe ich das Quell-Log gezippt angehängt (umbenannt in .txt)

Gruß,
Markus

 

[Pulsar07]

Hi Markus,
habe mir die Sache angeschaut und das Problem gefunden. Um die diversen Sensor-Werte zu identifizieren, muss das Tool Annahmen über die Namen der Sensor-Werte machen. So nimmt mein Tool an, dass alle Sensorwerte mit Pattern .*Hoehe.* die Flughöhe sind. Dein Vario hat allerdings einen zweiten Sensorwert, den "Hoehengew.". Der passt leider auch in mein Pattern und überschreibt deshalb leider den richtigen. Die angezeigten Werte sind die des Sensor-Wertes "Hoehengew."
Werde die Tage ne neue Version machen, die diesen Fall dann besser ab kann.

Gruß Rainer

 

[Pulsar07]

Aus Tage werden Monate .... Sorry mir ist ein großes Projekt dazwischen gekommen ;-)
Habe unter https://github.com/Pulsar07/JetiLogAnalytics ne neue Version 0.2.7 eingecheckt, die das Problem mit dem "Hoehengew." behebt.
Gruß Rainer

 

[Smart]

Kurzes Feedback: Höhe (min(max/durchschnitt) wird jetzt korrekt ausgewertet. Danke!

 

[Pulsar07]

Habe aufgrund von Rückmeldungen noch ein weiteres Konfigurationsfeature eingebaut, um die Sensitivität der Flugerkennung anpassen zu können.
Die Software ermittelt aus den beiden Antennensignalstärken A1 + A2, ob das Modell schon in der Luft ist. Ein Modell ganz nahe am Sender hat meist beide Werte auf 9. Sobald man das Modell vom Sender weg bewegt, sinken die Werte im Mittel recht schnell. Die Antennenwerte A1 + A2 hat jeder mir gekannte Log.
Ohne das neue Feature wird die Summe der beiden Werte auf <15 geprüft und dazu noch etwas die Wertefolge geglättet.
Das funktioniert bei mir sehr gut, da ich mit meinen Modellgrößen sofort >50m Entfernung habe.

Aufgrund einer Rückmeldung eines DLG Piloten, ist das aber für kleine Modelle die in sehr kleiner Entfernung zum Pilot geflogen werden zu grob und es wird der Flug nicht erkannt/ausgewertet. Deshalb kann man nun im GUI oder auch als Parameter die Sensitivität erhöhen und bekommt gute Resultate.
Auf der Kommandzeile sollte hierfür angegeben werden:
--sensi <value> sensitivity used for flight detection, float range: 0.0-1.0
im GUI gibt es dafür einen neuen Schieberegler.

Mit den neuen Feature wird weniger gegättet und der Summenschwell-Wert auf bis zu knapp unter 18 erhöht.


Gruß Rainer