J-Log.eu - Forum

Eine Besonderheit haben wir noch, resultierend aus dem Verfahren für die T-Box, was dann auch für die anderen Terminals rückwirkt..:
“Distanz” (mAh) ist die Hypotenuse im Dreieck. Laut Kollegen Pythagoras (leider früh verstorben ) muss es die längste Seite im Dreieck sein. Ergo muss JLog “Höhe” (rpmU/10) solange in der Telemetrieausgabe auf Null halten, bis mAh wenigstens denselben Wert hat. – Wer nur mal schnell trocken testet, soll also nicht gleich “Bug!” schreien, wenn er die Rotordrehzahl steigen sieht, die mAh auch, doch plötzlich springt die Drehzahl auf Null. Tja.., da muss er noch etwas länger laufen lassen, dass rpmU/10 wiederkommt, denn glücklicherweise steigt meist die Drehzahl schneller, als mAh verbraten werden. – Das heißt aber auch, lieber Anwender: Wenn Du vergisst, das Ratio (die Untersetzung) mit JLC einzustellen, rpmU/10 wäre dann wegen 1:1 ein Zehntel der Motordrehzahl, dann musst Du wohl ziemlich lange warten, bis Du soviel mAh gesaugt hast wie numerisch ein Zehntel Deiner Motordrehzahl. —- ….. Um es nun nicht noch unnötig zu verkomplizieren, kann man JLog NICHT unterscheiden lassen zwischen T-Box und T18MZ/T14SG, sein Wirken auf “GPS/Höhe” (rpmU/10) ist also dasselbe für T18/T14, obwohl die es nicht brauchen, weil sie “GPS/Distanz” (mAh) vom Bus nehmen. Je höher diese Drehzahl ist, je geringer der Verbrauch ist, um so länger dauert es, bis rpmU/10 von Null auf den Momentanwert springt. Beispiel: Rotordrehzahl==2000. Dann passiert das bei 200mAh. Am längsten wird es also bei einem 450er Heli dauern, hohe Drehzahl, geringer Verbrauch. Es sollte aber eigentlich nicht stören, denn auf diese Drehzahl wird man kaum einen Alarm setzen wollen, und auf’s Display schaut man eh kaum beim Fliegen. Einzig, wenn man die Rotordrehzahl eines Helis vor dem Abheben kontrollieren will, könnte das kurzzeitig hinderlich sein.

Zunächst: Ärmlicherweise gibt es keinen Alarm für unterbrochenen Downlink. Außerdem gehen alle Displaywerte einfach in Hold, zeigen den letzten empfangenen Wert. Allerdings kann man die Empfängerspannung dafür benutzen (Empfänger als Sensor): Man setzt einen Alarm auf Unterschreiten von knapp über Null Volt, – das Display geht auf Null nach Timeout, wenn nichts mehr empfangen wurde seitens Telemetrie. – Einen Stop akustischer Alarme oder von Vibrationsalarmen (per Taste) gibt es leider nicht in den Futaba/Robbe-Terminals (T18MZ, T14SG, T-Box).
Was es allerdings gibt: Alarme im Terminal werden gestoppt, sobald der Downlink ausfällt.

Nun zu den Alarmen mit Jlog2. Hier gilt es, zwei Probleme zu lösen:

1. — JLog “mißbraucht” verschiedene Futaba-Sensortypen, es müssen ja registrierbare sein, zumindest für T14SG und T-Box. Die Wahl der Sensoren erfolgte nach drei Gesichtspunkten: a) Wertebereiche der Displays und Alarmschwellen, b) möglichst wenig Sensoren wegen des Aufwands des Registrierens, c) sollten noch genug Timeslots (von 31) für andere Sensoren frei bleiben (ein GPS-Sensor, z.B., frisst 8 Slots für 4 nutzbare Displays).
Die Alarmbereiche und -schwellen (Überschreiten/Unterschreiten) der verwendeten Displays (Vario, Temp, GPS) müssen zu den eingesetzten Werten passen bzw. mit Hilfe von JLog als Alarmgeber passend gemacht werden.

2. — Da der S.BUS2 eigentlich keine Alarmgeber kennt (==Sensoren), sondern immer nur das Terminal Alarme bilden kann, gibt es keine Zustandsabhängigkeit von Alarmen, z.B., dass trotz wertemäßig bestehender Alarmbedingung kein Alarm ausgelöst wird, weil gerade kein Datenstrom vom ESC als virtueller Multisensor kommt. Das Terminal kennt nur werteabhängige Alarme, kann nicht bewerten, ob Momentanwerte evtl. nicht zu einem Alarm führen sollten. – Das ist der Grund, weshalb ich Sensoren als Alarmerzeuger bevorzuge.
Nun wird es zu Fehlalarmen kommen, insbesondere, wenn alle Werte auf Null stehen, weil JLog oder der ESC noch nicht initialisiert haben, oder weil der ESC gerade ausfiel wegen Akkuwechsel.

Und so wird’s gemacht .. (Hinweis, teilweise habe ich erst letztes Wochenende noch was am “Alarmwesen” von JLog mit Futaba-Telemetrie gemacht. Die resultierende Firmware (25.02.2013) findet sich im Download.):

Vario m/s (Steig-/Sinkrate) und Vario m (Höhe) geben es leider nicht oder nicht nutzbar her, dass man auf Unterschreiten eines positiven Wertes einen Alarm im Terminal setzen kann. Daher werden hierfür die Alarme im JLog gebildet und die Schwellen per JLC eingestellt! JLog negiert den Momentanwert (negatives Vorzeichen), um einen Alarm zu signalisieren, – obwohl so etwas, Sensor als Alarmerzeuger, der S.BUS2 nicht vorsieht.

Man setzt nun einfach einen Alarm im Sender, dergestalt, dass der bei Unterschreiten von Null kommt. – Und bingo, so haben wir auch gleichzeitig unser Zobie-Alarm-Problem bei Nullen gelöst.

Leider erlauben nicht alle relevanten Displays auch negative Werte, GPS/Distanz z.B. nicht, was wir für die “mAh” nutzen. – ”mAh” und Min/Max-Werte (Min/Max nicht in die Futaba-Telemetrie gegeben) werden bei Ausfall des ESC (Akkuwechsel) nicht genullt, – man will ja noch gemütlich ablesen nach dem Flug, – sondern erst dann, wenn der Datenstrom des ESC nach Akkuwechsel wieder sichtbar wird. Das Ganze nennt sich “Multisessionfähigkeit” des JLog, “Warmstartfähigkeit”, spielt aber nur eine Rolle, wenn JLog nicht zusammen mit dem ESC aus geht bei Akkuwechsel. – Ergo wird ein mAh-Alarm weiter rappeln, solange man nicht wenigstens mal kurz den Antriebsakku wieder an den ESC nahm, ihn wechselte, oder eben JLog rebootete.

Es kann weitere Alarme geben, die im Terminal (Sender, T-Box) definiert werden und uns zwischen den Flügen fortgesetzt ihr Lied singen könnten:
- Temperaturalarme auf JLog-eigene Sensoren (hier nur “extT1″, oder wie immer man es titulieren will).
- Ein Drehzahlunterschreitungsalarm auf JLog’s eigenen Drehzahlsensor, z.B. für Mindestrotordrehzahl bei ARs.
- Ein Unterschreitungsalarm auf “Speed” (JLog-eigener Sensor). .(Hier könnte ich noch was machen, weil JLog auf Speed auch selbst Alarme bildet.)

Für folgende Daten werden Alarmschwellen per JLC eingestellt, und JLog meldet Alarm per Umpolen des Momentanwertes, – das Terminal erzeugt seinerseits Alarm auf Unterschreiten von Null:
- Ubec (U BEC Dip Alarm) – auf Vario 2 / m/s (Steig-/Sinkrate – “Vario”)
- Ubat — auf Vario 2 /m (Höhe)
- JLog’s Voltage Sensor (Spannung) – auf Vario 3 / m/s (Steig-/Sinkrate – “Vario”).
(Voltage Sensor und ext Temp1 sind dieselben Werte, mal Spannung, mal Temperatur, je nach Setup des JLog.)

Vor dem Initialisieren des ESC:

.. Screenshots... Bitte im obigen Link betrachten/lesen

Während des Fluges:.

Nachdem der ESC spannungslos wurde:.

Der Alarm auf “eRPM/10″ (JLog-externe Drehzahl) ist im Sender gesetzt, auf Unterschreiten einer minimalen Drehzahl (z.B. Rotordrehzahl während einer AR). “Uext” ist eine mit JLog-eigenem Sensor gemessene Spannung. Der Alarm wird durch JLog erzeugt, das Auslösen im Sender erfolgt, indem man einen Alarm auf Unterschreiten von Null setzte, – JLog negiert die Spannung bei Unter- oder Überschreiten der in JLC eingestellten Schwelle. Dieser Alarm ist unabhängig vom durch JLog gesehenen Betriebszustand des ESC. “kmh” ist die mit JLog-eigenem Sensor gemessene Geschwindigkeit. Im Sender wurde ein Lowspeed-Alarm gesetzt. Auch dieser Alarm ist unabhängig vom Betriebszustand des ESC. “mAh” ist zwar ein rein JLog-eigener Wert, kann aber nicht zustandsabhängig zurückgenommen werden, wenn der ESC stromlos wird, damit man die mAh nach dem Flug erst ablesen kann. Das Rücksetzen auf Null erfolgt erst, wenn der Datenstrom des ESC erneut von JLog gesehen wird (erneutes PowerOn).

Und noch eine Besonderheit.. Also, Konsistenz der Funktionalität zwischen Futaba und Robbe zu verlangen (T18MZ vs. T-Box), ist ja vielleicht ein bisschen zu viel verlangt, aber Konsistenz zwischen T18MZ und T14SG scheint leider auch ein Fremdwort zu sein: Im Gegensatz zur T18MZ macht die T14SG für Werte “Höhe” (in VARIO und GPS) Folgendes: Sie zeigt nicht den Wert, den sie via S.BUS2 bekommt (von JLog2), sondern sie zeigt die Differenz zwischen dem Einschaltwert (gelesen, wenn Sender eingeschaltet wird) und Momentanwert. Bingo! Was für ein Blödsinn, so was ist doch Sache des Sensors! Sieht aus wie ein klammheimlicher und ungeeigneter Versuch, Sensorfehler im Display heilen zu wollen. So langsam fällt mir nichts mehr ein, was man zur Entschuldigung von Futaba noch beibringen könnte.. — Der Effekt von der Sache: Schaltet man den Sender mit laufender Telemetrie ab und wieder an, zeigt er zumindest in allen VARIO/Höhe Blödsinn.