Alarme und Absonderlichkeiten

Futaba Telemetrie kennt im Gegensatz zu anderen Systemen, wie Multiplex, JETI, HoTT und teilweise SPEKTRUM, keine Alarme, die ein Sensor signalisiert. (JR und HiTec auch nicht.) Alarme werden ausschließlich im Terminal gebildet, Sender bzw. Robbe’s T-Box. Dazu kann man an jedem Sensordisplay zwei Alarmschwellen definieren, je nach Bedarf, – eine auf Überschreiten eines Wertes, eine auf Unterschreiten. Mögliche Unterschreitungsalarmschwellen werden davon abhängig sein, ob dieses Sensor(teil-)display auch Werte mit negativem Vorzeichen kennt.

Die meisten Anwender bevorzugen es, Alarme am Sender definieren zu können, aber eigentlich ist es vorteilhafter, wenn der Sensor die Alarme generiert. Grund ist, dass es der Sensor statusabhängig machen kann. “Statusabhängig” heißt, nicht allein das Erreichen einer Alarmschwelle, rein bezogen auf den momentanen Wert, ist ausschlaggebend dafür, ob ein Alarm ausgelöst wird, – es ist auch wichtig, ob der gegenwärtige Betriebszustand einen Alarm rechtfertigt. Beispiel: Wenn die Verbrauchsschwelle (mAh) erreicht ist, löse ich definiert einen Alarm aus. Wenn das Modell aber gar nicht mehr in der Luft ist, macht das keinen Sinn, nervt nur. Nur kann eben nur der spezialisierte Sensor wissen, wie die Zusammenhänge sind, nicht das Terminal.

Empfängt der Sender/T-Box keine Daten mehr vom Empfänger, dann gehen seine Sensor(teil-)displays sozusagen in “Hold”. Ausnahme sind die beiden Spannungen vom Empfänger, sie gehen dann auf Null. Das kann übrigens auch für einen Verbindungsalarm benutzt werden, denn so was gibt es ansonsten nicht in der Futaba Telemetrie.

Es gibt somit drei Chancen für “Zombie Alarme” bzw. unnötige Alarmzustände:
…..* Unterschreitungsalarme, die durch einen Nullwert ausgelöst werden, wenn man einen Unterschreitungsalarm
…..  auf Werte größer Null eingerichtet hat. So ein Alarm kommt dann gleich nach dem Einschalten,
…..  wenn vom Sensor noch keine Daten >Null kamen.
…..* Alarme von Displays, deren Wert einfror, “Hold”, weil die Verbindung zum Empfänger weg ist.
…..* Last but not least berechtigt aktive Alarme, die ich einfach nicht los werde:  Der Sender/T-Box kann mit seinen
…..  Alarmschwellen nur Alarme aktivieren, ein betriebszustandsabhängiges Pulsen von Alarmen könnte nur der
…..  betreffende Sensor machen. Leider gibt es bisher auch keine Möglichkeit, am Sender/T-Box einen aktiven Alarm
…..  stumm zu schalten.

JLog versucht daher, sich für einige Werte in die Rolle eines alarmierenden Sensors zu versetzen. Das funktioniert durch Wertänderung im Alarmzustand, man muss eine korrespondierende Alarmschwelle setzen im Sender/T-Box. Sinn des Ganzen ist, obige “Zombie Alarme” vermeiden zu können.

Beispiel 1:
Das mAh-Display des Sensors F1678 kennt sinnloserweise ein negatives Vorzeichen, zum Glück. Definiert man einen mAh-Alarm in Jlog (im JLC), dann gibt JLog dem momentanen mAh-Wert ein negatives Vorzeichen, wenn die Alarmbedingung eingetreten ist. Im Sender/T-Box setzt man einfach nur einen Alarm auf Unterschreiten von Null. Damit hat JLog die Möglichkeit, den Alarm betriebszustandsabhängig zu deaktivieren, nämlich bei Unterschreiten von 10% Gas oder PWM (KOSMIK in Ermangelung von Gas). Das nennt sich “CAPALARMSTOP”, realisiert mit allen Telemetrien. Der Sender nervt nicht weiter, wenn man gelandet ist. Außerdem pulst JLog den Alarm, 5s aktiv, dann 20s Pause, wenn Gas bzw. PWM>=10%, 40s Alarm-Pause, wenn Gas/PWM<10%.
Alternativ kann man einfach keine Alarmschwelle auf mAh in JLC definieren, und setzt ganz regulär einen Überschreitungsalarm auf einen mAh-Wert im Sender. Das heißt natürlich, dass nach Erreichen der Alarmschwelle Sender/T-Box nicht aufhören werden, zu rappeln.

Beispiel 2:
Spannungsalarm, hier auf “Ubat”:  Ein Alarm im Sender auf Unterschreiten von x wird natürlich auch bei Null im Display ausgelöst. Leider kennt das Spannungsdisplay des von JLog dafür benutzten Sensors F1678 keinen negativen Bereich (dafür die mAh ). JLog addiert nun einfach 50V auf den Momentanwert, um Alarm zu signaliseren. Im Sender/T-Box setzt man einen Alarm auf Überschreiten eines Spannungswertes, der mit der Batterie nicht erreichbar ist. Der Nullwert-Zombie-Alarm ist somit auch hier ausgehebelt. Leider lässt der Wertebereich des Spannungsdisplays es nicht zu, einen geraden Wert wie 100 zu addieren, schließlich muss das Ganze bis 16S funktionieren können.

————————————————————————————————————————-

Absonderlichkeiten

Die Sensoren Vario F1712 und GPS F1675 haben ein Teil-Display “Höhe”. Die Höhe basiert in beiden Fällen auf der barometrischen Höhenformel, kommt von einem Drucksensor. Nun könnte man ja annehmen, dass so ein Drucksensor seine Startup-Problemchen und initiales Nullsetzen mit sich abmacht. Man könnte auch generell erwarten, dass das Terminal, Sender, T-Box, immer das anzeigt, was ein Sensor ausgibt.

Leider nicht: Sender/T-Box setzen einen Wert “Höhe” bei ihrem Start auf Null, sie “Nullen”. Beispiel:  Ein Sensor gibt für “Höhe” einen Wert aus, der als “9m” dargestellt werden würde. Nun wird der Sender gestartet, der zeigt aber “0m”. Restarte ich jetzt den Sensor, und der gibt “0m” auf den Bus, dann zeigt der Sender “-9m”. Das kann zum Irrenhaus ausarten, vor allem, wenn man den Sender bei aktiven Displays (ungleich Null) neu startet.

Sensor F1675, GPS:  Es gibt das Teil-Display “Distanz”. Der Sensor (GPS Empfänger) liefert diesen Wert. Er versteht “Distanz” als Luftlinienentfernung Pilot–Modell.

Nun kam Futaba später auf die Idee, es anders zu machen, einstellbar am Terminal (Sender), auf jeden Fall ist mal wieder die Basis, das der vom Sensor gesendete Wert ignoriert wird, Sender/T-Box rechnen es sich selbst aus. Für die Entfernung Pilot–Modell passiert das nach dem Satz des Pythagoras, rechtwinkliges Dreieck, “Distanz” ist die längste Seite “c”. Die anderen Seiten sind “Höhe” (tolle Sache, da motscht der Sender auch drin rum..) und GPS-Entfernung des Modells, also in Projektion auf den Boden.

Wen wundert’s, dass die alternative Einstellung im Sender die GPS-Entfernung ist.

————————————————————————————————————————-

Bugs

Es wäre falsch, das Folgende unter “Absonderlichkeiten” zu erwähnen.
Es gibt da so manches, einige Design Bugs wurden auch gefixt, inzwischen, – hier soll es nur um Alarme gehen:

Die Reihenfolge der Displays in der Gesamtansicht bestimmt sich aus der Reihenfolge der Sensorregistrierung, also der jeweiligen Start-Slots der Sensoren. Ist nun ein (Teil-)Display eines Sensors mit einem Alarm besetzt, dann wird dieses optisch markiert und vom User definierte andere Alarmgeber kommen on top, – Sprache, Vibrator.  –  Leider ist nun so, dass ein Alarm auf einem Senor, der in der Abfolge vor anderen registriert ist, Alarme auf nachfolgenden maskiert. Deren Displays werden zwar noch markiert, das sieht man aber evtl. gerade gar nicht, die zugehörige Sprachausgabe zumindest kommt nicht, solange der Sensor davor noch Alarmbedingung hat.

Nicht gut.. Die T-Box ist ja eine Entwicklung von Robbe, und die macht das ganze Alarm Handling von Anfang viel besser und intelligenter als die Sender von Futaba. Man kann vor allem die Alarme mit einer Verweildauer besetzen, was Alarmen auf nachfolgenden Sensoren eine Chance gibt.