failsafe / loss of telemetry loggen

strgaltdel

Erfahrener Benutzer
#1
Hi,

habe mich gestern mal daran gemacht wie man failsafe / loss of telemetry mit Bordmitteln im Log leichter erkennen kann.
Out of the box sieht man es ja nur, wenn sich etliche Zeilen wiederholen und unplausible Werte ergeben
(z.B. ständiges Steigen ohne Höhenzuwachs)
Hier mal meine Umsetzung:

(1)
- LS definieren, der "Loss of Telemetry" erkennt (auch FS löst dies aus)
telem.jpg

(2)
- u.a. script nach \SCRIPTS\MIXES kopieren
.. das mini-script liest LS27 aus und generiert bzw füttert einen Telemetrie Sensor namens "tele":
0 >> keine Telemetrie
1 >> Telemetrie vorhanden
Name/LS# kann man sich leicht selbst anpassen


(3)
script im Modellspeicher aktivieren
script.jpg


(4)
nochmal Sensorsuche ausführen
Nun steht "tele" als Sensor zur Verfügung



Bsp-Log:
Status 0 = loss of telemetry durch Ausschalten provoziert

log.jpg


Auffälligkeiten beim Workbench-Test

- Die Latenz des LS beträgt geschätzte 0,6 Sekunden.
In der Zeit kann ein XR-8 z.B. komplett rebooten.
Ein Ausfall für so kurze Zeit wird daher NICHT erkannt !
Andersherum formuliert:
schlägt der Sensor an, ist der Incident bereits eine halbe Sekunde zuvor passiert !

- Die oTx Meldung "Telemetrie Verloren" kommt noch später, geschätzt 0,8 Sekunden.
Es kann daher Situationen geben, dass der Sensor kurz angeschlagen hat, obwohl keine Warnmeldung durch oTx erfolgte !




Grüsse

Udo
 

Anhänge

r41065

Erfahrener Benutzer
#2
Bin mal wieder aus beruflichen Gründen von meiner Hobbyausrüstung getrennt, so das ich nicht wirklich was testen kann...
nur so ne Idee beim ansehen des Script:
Wie wäre es denn Mit den Werten Telemetrie OK = 0 und wenn nicht OK einen Zähler hochlaufen lassen, dann hat man eventuell direkt eine Abschätzung wie lange der Aussetzer gedauert hat....
Ralf
 

strgaltdel

Erfahrener Benutzer
#3
Hi Ralf,

openTx ist nicht wirklich ein Multitasking Betriebssystem.
einfach nur Zähler hochlaufen lassen ist kein exaktes Äquivalent für eine bestimmte Zeit, da man nicht wirklich weiss wie häufig das skript CPU-Zeit bekommt,
Das ist von der Hintergrundlast abhängig.

Man kann die Systemzeit sehr exakt abrufen und dadurch die Dauer auf Zeitbasis einigermassen bestimmen.
Ich würde dann aber lieber einen 2. Sensor generieren, der die Summenzeit darstellt, da der vorhandene (für mich) einfach nur ein flag sein soll.
Ist dann aber auch nur eine grobe Annäherung, da das Latenz nicht enthalten ist.
Wenn man "die Ausfälle" exakter haben möchte würde ich Tadangos Lösung mit dem Arduino (frame loss rate Indikator) mit an den SPORT hängen.

Gruss
 

r41065

Erfahrener Benutzer
#4
Tadangos Arduino Lösung hab ich im Einsatz, der zählt die Frameloss des SBus ..

War ja nur ne Idee , das das keine genauen Zeitwerte liefen kann war mir schon klar, ob der Ausfall aber 5 oder 50 Zyklen dauert kann man dann schon Abschätzen, vor allem wenn die Aufzeichnung des Logfile mit relativ lange Zykluszeiten erfolgt....

Ralf
 

strgaltdel

Erfahrener Benutzer
#5
...So aehnlich habe ich bis vor ein paar Tagen auch gedacht.
Kilrah/Andre hat das aber dann mal erlautert.
Der "Trigger" fuer den LS (bzw die Tele lost Erkennung) wird seitens oTx an der Uebertragung des RSSI Wertes festgemacht.
Und diese Uebertragung ist recht traege und volatil.

Die Erkennungsgeschwindigkeit bzw der Messfehler fuer die Ermittlung der Ausfallzeit ist daher noch groesser als 2 Zykluszeiten der Log-Schreibgeschwindigkeit.

Daraufhin bin ich dann von dem Thema wieder weg...

Udo
 
#6
Und diese Uebertragung ist recht traege und volatil.
Udo, mach bitte meinen geliebten SPort nicht so schlecht ;) Ich denke, dass Kilrah meinte, dass RSSI nicht mit hoher Frequenz gesendet wird und diese auch noch variabel ist, je nach Anzahl der übertragenen Sensoren. Deswegen mussten sie ein relativ hohes Delay vorsehen.
 

strgaltdel

Erfahrener Benutzer
#7
Ja genau, war wohl misverständlich ausgedrückt, mit "Diese Übertragung" war speziell die vom RSSI Wert gemeint. Ich hätte auch schreiben können
"Die Übertragung des RSSI Wertes ist träge und ausserdem noch unregelmässig" ;)
Also nix gegen deinen SPort :engel:
 
#8
Aus meinem letzten Arbeitszeugnis konnte ich diese Formulierung erfolgreich herausklagen:
"Er arbeitete stets träge und außerdem noch unregelmäßig." ;):)
 
RCLogger

FPV1

Banggood

Banggood

Oben