Skript zum Aufspüren von Lock Outs

[fsjunk]

ich möchte hier nochmal mein Script zur Auswertung von Telemetriedaten vorstellen.
Es durchsucht Logdateien nach "eingefrorenen" Werten als Indiz für LockOuts.

Kriterium: alle Sensordaten liefern für mind. 800 ms unveränderte Werte.

Als Ergebnis entsteht eine neue Logdatei, die diese Problembereiche (inkl. 5s Vor-/Nachlauf) als einzeln anwählbare Sessions enthält. So kann man auch in größeren Dateien die relevanten Stellen direkt anwählen.



Im Companion Log Viewer wird der betroffene Bereich mittig dargestellt.

Das Script kann Lock Outs nicht von tatsächlich unveränderten Werten unterscheiden. Aber je mehr Sensoren enthalten sind, umso weniger "Falschmeldungen" sollten auftreten. Voraussetzung ist auch, dass das Loggen in möglichst kurzen Intervallen (0,1 o. 0,2 s) erfolgt.

 

[Carbonator]

Ich bin hell begeistert! So kann jeder, der Lockout gefährdete Hardware nutzt und schnelle Logs hat, vorzugsweise mit Vario, mal schnell seine Dateien scannen. Verdachtsfälle können wir gerne hier diskutieren. Ich rieche die Lockouts mittlerweile

Ich freue mich schon sehr auf das Programm und die Anleitung.

 

[strgaltdel]

@fsjunk
nicht schlecht, aber ich denke du machst dir das Leben unnoetig schwer, wenn du so die "Sensor holds" mit ca 800ms aufspueren moechtest.
Was du machst ist ja im Grunde die "telemetry lost" Meldung abzufangen, das geht einfacher:
(1) LS auf das "Telemetrie verloren" Ereignis setzen
(2) Per script LS abfragen und daraus einen Telemetrie Sensor Status generieren.

So mache ich das jedenfalls seit Urzeiten um FS im Log zu flaggen.
Ist bequemer als alles andere.

Gruesse

 

[Carbonator]

Genau das funktioniert halt nicht, weil die Lockouts, um die es hier geht, eben keine "telemetry lost" Meldung auslösen. Sie sind schlicht zu kurz. Lockouts und Failsafes sind nicht dasselbe. Für den Failsafe-Fall hast du Recht.

 

[strgaltdel]

...
Ja, aber ich glaube diejenigen, die sich mit Thema befassen wissen was lockouts per Definition sind und was sie im jeweiligen Zusammenhang bedeuten.
Mir fallen halt nur zwei lockout Szenarien im Rx Umfeld ein, dass eine ist halt der FS und zum anderen wurden nie genauere Infos publiziert, daher habe ich Probleme damit "irgendein Timing" als lockout-detector / trigger anzunehmen.
Der FS ist definitiv ein lockout Szenario, ansonsten kollidiert man ein wenig mit der "Lehre der Nachrichtentechnik". Jedenfalls war das vor Jahrzehnten mal so, als ich das mal in einem Unterrichtsfach hatte!

Zudem meines Erachtens nach es sich niemand in den ganzen Diskussionen die Muehe bei Nutzung des Begriffes "lockout" machte zu schreiben, welche Art von lockout er auf welchem device, Rx oder FC, er jeweils meinte.

Wobei ich beim Thema FC lockout sowieso aussen vor bin.
Gibt es da Differenzierungen hinsichtlich der "Massnahmen", ggf FC SW/HW abhaengig?

 

[Carbonator]

Mike Blandford gilt allgemein als ziemlich guter Kenner der Materie, es geht um den Lockout, den er hier beschreibt:
"It could affect the channel hopping, which would lead to the 0.9S lock out. "
"Unser" Lockout entsteht, wenn der Empfänger neu auf die Hopping Tabelle synchronisieren muss.

 

[strgaltdel]

Bernd,

das ist doch alles bekannt, Mikes Aussage gibt da keine genauere Auskunft ueber die Erkennung, lediglich ueber die Minimun-Overall Processing time.
trotz mehrfacher Anfrage habe ich nie eine Antwort erhalten.
Und die entspricht dann wieder genau der FS Ausloesezeit und wird damit nicht unterscheidbar.
Gerade der zeitliche Ablauf detection / reaction waere wichtig zu wissen,

Ausserdem widersprichst Du dir mit dem link gerade selbst.

Sie sind schlicht zu kurz

 

[fsjunk]

aber ich denke du machst dir das Leben unnoetig schwer, wenn du so die "Sensor holds" mit ca 800ms aufspueren moechtest.

war eine gute Übung für den Einstieg in Python. Als OTX-Einsteiger kann ich nicht einschätzen, ob das Script brauchbar ist. Die Idee war, dass man auch vorhandene Log-Archive analysieren kann.

Das Script habe ich auf GitHub abgelegt. Python muss installiert sein. Aufruf in der Kommandozeile; als Argument die zu analysierende Log-Datei u. optional die Mindestzeitspanne in ms (default: 800).

Zur Verarbeitung von mehreren Dateien nutze ich die For-Loop. Könnte man aber auch in das Script integrieren (z.B. Suche durch Unterverzeichnisse).

 

[Carbonator]

Ausserdem widersprichst Du dir mit dem link gerade selbst.

Nein, ich widerspreche mir nicht, du verstehst nicht. Das Script findet sowohl Telemetrie Lockouts, wie auch die kürzeren Synchronisations-Lockouts in Logfiles. Dein Vorschlag lässt dich nur Telemetrie Lockouts finden.

 

[strgaltdel]

Hi Bernd,

"du verstehst nicht " du aber auch nicht (-;

""It could affect the channel hopping, which would lead to the 0.9S lock out. "

die Probleme im Channel Hopping initiieren den resync (stay & wait) und dementsprechend bedeutet "sync" oder "hopping" lockout, angeblich 0.9sec Ausfall.
Bisher ist das die einzige Aussage von Mike die einen Anhaltspunkt für Gesamtdauer einer Neusynchronisation
(Erkennung & Behebung) gibt.

Wo findest du Dokumentation, wie lange die Erkennungsphase sowie die Neusync Phase andauert,
danach suche ich schon seit Wochen....

 

[Carbonator]

Wo findest du Dokumentation, wie lange die Erkennungsphase sowie die Neusync Phase andauert,
danach suche ich schon seit Wochen....

Du weißt, dass ich Praktiker bin Ich kann dich mit Auswertungen von @fsjunk s Skript zuwerfen, aus denen die Lockout Zeit ziemlich genau hervorgeht. Wichtig ist aber doch nur, dass "Telemetrie verloren" den Sync-Lockout nur in Ausnahmefällen anzeigt. Seit dieser Erkenntnis ist mein Threadtitel im Nachbarthread nur unzureichend genau. Er hätte heißen müssen: "Vorsicht bei Lockouts mit 'neuer' FrSky Hardware" Aber wir sind der Sache auf der Spur.

Ich bin immer begeisterter von diesem Skript. Leider braucht man schnell updatende Sensoren und eine hohe Logfrequenz. Das Skript wird dem gemeinen FrSky User also leider wenig nutzen. Da wird die Luft dünn.