JLog2 + Futaba FASSTest® (S.BUS II)

———————————————————————————————————————————————————————
Ganz neu (27.07.2013):
Nachdem der Futaba Drehzahlsensor SBS-01RM/O erschien, vor allem aber der Stromsensor Robbe F1678, gibt es die Chance, eine seitens der verwendeten Maßeinheiten praxisnahere “Vergewaltigung” der Sensoren für die Zwecke von JLog (2 und 2.5) vorzunehmen.
Ein anderer, wesentlicher Grund ist, dass die Terminals, vornehmlich im Augenblick alle Sender, immer mehr dazu übergehen, NICHT das in einem Display darzustellen, was ein Sensor auf den Bus gibt, sondern den dargestellten Wert stattdessen selbst zu bestimmen. Eigentlich ein prinzipielles Unding, ist aber die zu berücksichtigende Praxis. — Die Robbe T-Box begann damit, indem sie “GPS Distanz” selbst berechnete. Inzwischen tun das alle Sender, sogar konfigurierbar nach Distanz als Luftlinie zum Modell oder Distanz als Differenz der GPS-Position des Modells zur Startposition (Entfernung am Boden, Modellposition auf den Grund projiziert). Wir nutzten “GPS Distanz” zur Ausgabe der “mAh”, gaben das auf den Bus, und die T18MZ stellte das (bisher) auch so dar. Für die T-Box, inzwischen zwangsläufig auch alle Sender, rechneten wir mit (rechtwinkliges Dreieck aus GPS-Abstand, Höhe und Luftlinien-Distanz) nach dem Satz des Pythagoras und drehten unter Berücksichtigung der Höhe (hier geben wir RPM Uni (Rotor) /10 aus) an den GPS-Koordinaten, um unseren Wert in “GPS-Distanz” erscheinen zu sehen. Da unsere Distanz die Luftlinie zum Modell ist, die längste Seite in Pythagoras’ Dreieck, hielten wir außerdem Höhe (RPM Uni) solange auf Null, bis “mAh” mindest denselben Wert erreicht hat. — Nun fingen T14SG und FX-32 an (seit v2.4 vermutlich auch die T18MZ), alle Werte “Höhe” in allen VARIOs und GPS zu “Nullen”. Der Sender nimmt den Wert, den er beim Einschalten sieht, als virtuellen Nullwert. Beispiel: Wir schalten den Sender an bei “Höhe==10m”, später gibt der Sensor Null Meter auf den Bus, – der Sender zeigt nun “-10m”.  –  Für die uns aufgezwungene Show mit Pythagoras, s.o., ist das ein zusätzliches Hindernis im Handling, es wird eine Gleichung mit zwei Unbekannten.  –  Die neue Sensorkombination, die “VARIO” und “GPS” unter Anderem aus dem eben genannten Grunde meidet, ist das hier die Lösung gegen eine praxisfremde “Kreativität” des Entwickler von Futaba.
Da die Firmware der T-Box bisher weder SBS-01 noch F1678 unterstützt, ist für Setups unter Nutzung der Box die jeweilige bisherige JLog-S.BUS2-Firmware zu nutzen, – für alle Sender sollte man eine andere (neue) Firmware (F1678, SBS-01, F1713) verwenden!
26. August 2013: Das Firmware Update v.1003 für die Robbe T-Box ist online. Damit kann jetzt für diese als Terminal dieselbe JLog Firmware verwendet werden wie für alle Sender!
JLog registriert sich wieder als 8 Sensoren,
- Robbe F1678 Stromsensor
- Futaba SBS-01 RM/O Drehzahlsensor
- 4x Robbe F1713 Temp.sensor
- Robbe F1678 Stromsensor
- Robbe F1713 Temp.sensor

Das Ganze belegt 12 Slots (vorher 18) und ergibt 3+1+1+1+1+1+3+1=12 Displays.

- erster F1678: “Current”==Imotor, “Voltage”==Ubattery, “Capacity”==mAh
- SBS-01: RPM Rotor (Sensor im Sender auf “magnetic”, “ratio 1:1.00″ stellen!)
- erster F1713: tFET (Temperatur der FETs in der Endstufe eines ESC)
- zweiter F1713: tBEC (BEC-Temperatur)
- dritter F1713: Gas (throttle) 0..100% (Anzeige als °C)
- vierter F1713: PWM 0..100% (Anzeige als °C)
- zweiter F1678: “Current”==Ibec, “Voltage”==Ubec, “Capacity”==externe RPM (JLog-eigener Sensor) oder Speed(km/h) (Anzeige als mAh)
- fünfter F1713: externe Temp. #1 oder externe Spannung 0..12,8V (JLog-eigener Sensor) (Anzeige als °C)

Alarme:
1ster F1678-Current – Imot: Hier wird man keinen Alarm brauchen, kann man aber im Sender setzen.
1ster F1678-Voltage – Ubat: Die Alarmschwelle wird im JLC gesetzt, bei Unterschreiten des Schwellwertes addiert JLog 50V. Im Sender setzt man den Alarm auf Überschreiten von 70V (oder weniger, je nachdem, wieviel S das Setup hat), – mehr als 70 geht leider nicht (100 wären gut gewesen), obwohl das Display auch über 600 kann.
Wer das nicht will, setzt eines Unterschreitungsalarm im Sender und keinen im JLC, muss dann aber mit dem Zombiealarm bei 0 leben, je nach Setup des Modells und den Anwendungsgewohnheiten.
Leider kennt “Voltage” eines F1678 keine negativen Werte (vorher negierten wir Ubat im Alarmfalle und setzen im Sender die Alarmschwelle auf Unterschreiten von Null, umd bei Null keinen Dauer-Zombie-Alarm zu erhalten vom Sender), – wohl aber “Current” und “Capacity (mAh)”. Sehr praxisorientiert…
1ster F1678-Capacity – mAh: Alarmschwelle im JLC setzen, und im Sender auf Unterschreiten von Null. JLog gibt die momentanen mAh negativ aus im Alarmfalle. Darüber wird wie bisher das Pulsen des mAh-Alarmes durch JLog gemacht, 5s aktiv, dann 20s Pause, wenn Gas, bzw. PWM beim KOSMIK, >=10%, 40s Alarm-Pause, wenn Gas/PWM<10%. (Beim S.BUS2 kann ein Sensor ja nicht selbst einen Alarm generieren bzw. löschen.)

SBS01 – RPM Rotor: braucht eigentlich keinen Alarm

1ster F1713 – tFET: Alarmschwelle im Sender setzen

2ter F1713 – tBEC: Alarmschwelle im Sender setzen

3ter F1713 – Gas: braucht keinen Alarm

4ter F1713 – PWM: braucht keinen Alarm

2ter F1678-Current – Ibec: Hier wird man keinen Alarm brauchen, kann man aber im Sender setzen.

2ter F1678-Voltage – Ubec: Alarm im JLC setzen (Checkbutton UbecDip Detection), JLog addiert +50 bei Alarm. Im Sender setzt man den Alarm auf Überschreiten von 20V.

2ter F1678-Capacity, das wird ja, je nach Setup im JLC, für 2 alternative Zwecke verwendet:
- ext.RPM: evtl. Alarmschwelle im Sender auf Überschreiten/Unterschreiten setzen (AR-Mindestdrehzahl, z.B.)
- Speed: evtl. Alarmschwelle im Sender auf Überschreiten/Unterschreiten setzen (Max/Stall Speed). JLog gibt dem Displaywert ein negatives Vorzeichen, wenn MinSpeed unterschritten wird, im Sender einen Alarm auf Unterschreiten von Null setzen. Das hat den Vorteil, dass dieser Alarm von Jlog gesteuert werden kann, Stall Alarm gibt es erst, wenn MinSpeed einmal überschritten war.

5ter F1713, das wird ja, je nach Setup im JLC, für 2 alternative Zwecke verwendet:
- ext. Temp0: gewünschte Alarmschwelle im Sender setzen, negative Temperaturen sind möglich
- ext. Spannung (0..12,8V): Alarmschwelle im JLC setzen und Alarmschwelle im Sender auf Unterschreiten von Null. JLog negiert den Spannungswert im Alarmfalle. – Hier gibt es kein Komma, “128°C” == “12,8V”
———————————————————————————————————————————————————————

Achtung! Der Empfänger R7003SB hat einen Design Bug, der zumindest mit den gegenwärtigen Firmware Releases von VStabi auf dem S.BUS des R7003 zur Wirkung kommt. Siehe die Zusammenfassung hier!
Neues Alarmverhalten für mAh (GPS “Distanz”), siehe hier.
.
Folgend die “alte” Sensor-Nutzung durch JLog, 3xVARIO, 4xTEMP, 1xGPS, – nun nur noch für die Robbe T-Box, – übergangsweise, bis die T-Box auch die Sensoren SBS-01 und F1678 unterstützt:
Die ursprüngliche Implementierung der Futaba-Telemetrie für JLog2 (S.BUS2) erfolgte im April 2012. Zu diesem Zeitpunkt gab es nur den Sender T18MZ als “Terminal”. JLog2 verwendete nicht das Registrierungsverfahren für Futaba-Sensoren am Terminal, mit Zuweisung der Start-Slot-Adresse an einen Sensor, zumal es noch gar keine Futaba-Sensoren gab (JLog2 war der erste verfügbare S.BUS2-Sensor), sondern er nutzte die Fähigkeit der Firmware der T18, Sensoren manuell, sozusagen “generisch” definieren und Start-Slots zuweisen zu können. Das hatte den Charme, ausschließlich mit 1-Slot-Sensoren arbeiten zu können, Temperatur und vor allem RPM mit entsprechend großem Wertebereich. Der “Charme” konnte sich entfalten, weil man in der T18 Sensoren frei Bezeichnungen geben kann, und ein Sensorname gilt immer für alle Displays eines Sensors. Hat man nur 1-Display-Sensoren in Verwendung, kann man jeden Sensor individuell benennen. Leider kann man die “Unit”, die Maßeinheit, nicht ändern, und diese wird schließlich auch gesprochen.
Dann kam die Robbe Telemetry Box und nun auch die T14SG, und der schöne Spuk ist leider vorbei, Sensoren ohne Registrierung definieren zu können, den generischen RPM-Sensor zu verwenden (bis dato gab es keinen Futaba-RPM-Sensor, und ergo keinen registrierbaren RPM-Sensor) und Sensoren umbenennen zu können, – nur in der T18 geht das immer noch.
Die S.BUS2-Implementierung für JLog2 musste daher erneuert werden, JLog2 registriert sich als Futaba-Sensor, denn auf den Sanktnimmerleinstag eines registrierbaren Sensors “JLog” in den Firmwares der Terminals wollen wir ja nicht wirklich warten.  Genauer: JLog2 registriert sich als 8 Futaba-Sensoren. Das sind zum Teil Multisensoren,  -  mit individuellen Displaynamen in der T18 ist es daher leider vorbei, alle Displays eines Multisensors haben denselben Namen. Mit der T-Box und der T14SG geht das Umbenennen eh gar nicht.
Sensor #1
. Vario 1 Höhe == Imot*10  (100 m == 10.0 A) … Evtl. Alarm im Sender auf Überschreiten von x zu setzen.
. Vario 1 Vario == Ibec (10.0 m/s == 10.0 A) … Evtl. Alarm im Sender auf Überschreiten von x zu setzen.
Sensor #2
. Vario 2 Höhe == Ubat*10 (100 m == 10.0 V) … Alarm im JLC zu setzen und Alarm im Sender auf Unterschreiten von Null. JLog2 negiert den Wert zum Alarmieren, z.B. 42.7V –> -42.7V
. Vario 2 Vario == Ubec (10.0 m/s == 10.0 V) … Alarm im JLC zu setzen (Checkbox “Bbec-Dip-Alarm) und Alarm im Sender auf Unterschreiten von Null. JLog2 negiert den Wert zum Alarmieren, z.B. 4.3V –> -4.3V
Sensor #3
. Vario 3 Höhe == extRPM/10 (100 m == 1000 rpm) … Evtl. Alarm im Sender auf Über-/Unterschreiten von x zu setzen.
. Vario 3 Vario == extVoltage(extTemp1) (10.0 m/s == 10.0 V bzw. 10.0 °C) … Evtl. Alarm im Sender auf Über-/Unterschreiten von x zu setzen.
Sensor #4
. Temp1 == tFET (nativ in °C) … Alarm im Sender auf Überschreiten von x zu setzen, z.B. 85°C.
Sensor #5
. Temp2 == tBEC (nativ in °C)
Sensor #6
. Temp3 == PWM (100°C == 100 %)
Sensor #7
. Temp4 == extTemp1(extVoltage) (nativ in °C bzw. 100 °C == 10.0 V) … Evtl. Alarm im Sender auf Über-/Unterschreiten von x zu setzen.
Sensor #8
. GPS Höhe == rpmUni/10 (100 m == 1000 rpm) Rotordrehzahl, geteilt durch 10 … Evtl. Alarm im Sender auf Über-/Unterschreiten von x zu setzen.
. GPS Vario == Gas/10 (10.0 m/s == 100 %)
. GPS Speed == Speed (nativ in km/h)
. GPS Distanz == mAh (1000 m == 1000 mAh) … Alarm im Sender auf Überschreiten von x zu setzen, üblicherweise auf 80% der Nominalkapazität.
Um  JLog2 an den S.BUS2 anschließen zu können, benötigt man das Interface “JSend“, so und so sehen seine Details aus. Der S.BUS2 kam lange nach dem Design der JLog-Hardware, und seine Anforderungen sind nur mit etwas extra Hardware erfüllbar, in Form von JSend realisiert. Das elektrische Anschalten findet sich hier mit dem JIVE als ESC-Multisensor und hier mit einem Castle Creations ESC mit Castle Link Live.
Wie jeder Futaba-Sensor muss sich JLog2 erst am Terminal (Sender, T-Box) registrieren, nur, dass JLog eben 8 Futaba-Sensoren darstellt, in denen er mehr oder weniger passend die Displays für seine Daten finden kann. Beim Registrieren speichert das Terminal für sich die Sensortypen als Individuum (eindeutige Seriennummer) auf Slot-Adressen (1..31), die als einzig verwendeter Slot (TEMP125-F1713, 4x durch JLog verwendet) oder Start-Slot für Multi-Slot-Sensoren dienen, 2 Slots belegt VARIO-F1712 (3x in JLog) und 8 Slots durch GPS-F1675 (1x in JLog). Die virtuellen Futaba-Sensoren, die JLog2 darstellt, belegen also insgesamt 18 Slots. Die Registrierungsfunktion des Terminals berücksichtigt dabei die Regel, dass die 1(Empfänger)+31 Slots in 4 Frames á 8 Slots organisiert sind, und ein Sensor seine Slots immer in einem Frame haben muss. (In der operativen Praxis dann arbeitet JLog also, im Gegensatz zu Futaba-Sensoren, potentiell mit Slots, die über alle 4 Frames verteilt sein können, aber je Sensor im selben Frame.)
Registrieren
Im JLC unter “Telemetry” “S.BUS” auswählen und den “R” Button drücken, der wird dadurch rot. CONFIG.txt auf der mSD speichern, JLog damit starten. Das S.BUS2-Interface des JSend wird mit dem Sensor-Anschluss des Terminals verbunden. Nun in das Registrierungsmenü des Terminals gehen und 8x “Register” bzw. “Anmelden” drücken, hintereinanderweg, in einer Boot Session des JLog! Beim neunten Mal kommt es zu einer Fehlermeldung, weil JLog nicht mehr reagiert, seine 8 Sensoren sind angemeldet.
Folgendes ist zu beachten:
- Das R-Flag im Configfile wird beim ersten Start von JLog damit sofort wieder gelöscht, gleichzeitig löscht JLog seine Registrierung im Prozessor, im EEPROM.
- JLog2 befindet sich nun im R-Mode. Jetzt müssen unbedingt alle 8(!) Sensoren angemeldet werden, bricht man vor dem achten Sensor ab, ist die komplette Registrierung ungültig.
- JLog verbleibt im R-Mode bis zu seinem nächsten Boot. Vor operativer Verwendung des registrierten JLog muss dieser also restartet werden. Das ist so, weil der User theoretisch (lt. Command Set auf dem S.BUS2/Reg und seiner Reflexion im Menü der Terminals)  noch andere “Spielereien”  nach der Registrierung machen könnte. (Macht es besser nicht. :) )
Ergo sollte man vermeiden, mal aus Versehen das R-Flag im Configfile zu setzen per JLC, weil dadurch JLog seine Registrierung löschen würde, wenn er es beim nächsten Start sieht.
Bitte auch daran denken, sollte man mehrfach das Registrieren ausführen, vorher die alten Sensordefinitionen im Terminal zu löschen.
Hat man eine T18MZ, und nur dann(!), kann man noch die Sensoren umbenennen, es ist aber jeweils ein Name für alle Displays eines Sensors! VARIO-F1712 hat 2 Displays, TEMP125-F1713 1 Display (Gut!), GPS-F1675 hat 4.
Nun steckt man den S.BUS2-Anschluss des JSend um auf den Empfänger, restartet Jog, und los geht’s.
——————————————————————————————————————————————————————————————————
JLC: Select “telemetry”: “S.BUS2″ and click “R” (button getting red) to bring JLog in the register mode with the next start.
Connect JLog via JSend to your terminal (transmitter T18MZ, T14SG or Robbe T-Box).
Click 8 times(!) “register”. The 9th try will lead to an error.
Reconnect JSend to your receiver, reboot JLog, and voíla.
Note:
- JLog clears its registry status if the R flag in the config is seen to be set. So do not set the flag (by JLC) if you do not want to re-register!
- Jlog removes the R flag from the file immediately after startup so the next boot session will be an operational one.
- JLog stays in the R mode until next boot, even after registration of the 8th of the sensors it represents.
- JLog will reset its registration status if not all 8 sensors will be registered in one row.
- Jlog represents the following Futaba sensors: 3x VARO F1712, 4x TEMP125-F1713, 1x GPS-F1675, in that order.
Sensor renaming in the terminal: Only with the T18MZ!
Each display of a multi-sensor will get the same name.
——————————————————————————————————————————————————————————————————
.
Bzgl. der Stromversorgung bitte beachten:
Bekanntlich führt nur die Robbe T-Box die Betriebsspannung für Sensoren auf dem Anschluss zur Registrierung, T18MZ und T14SG nicht.  Allerdings bezieht JLog2 seine Betriebsspannung von JSend, und JSend bezieht diese NICHT vom S.BUS2, sondern via seinen JIVE-Anschluss. Verwendet man keinen JIVE als Spannungsquelle, mit einem Castle Creations, z.B., dann bitte beachten, dass der JIVE-Anschluss an JSend ebenso wie K5 des JLog2 und der Diagnostikanschluss des JIVE atypisch belegt ist: “Plus” ist nicht der mittlere Pin, sondern der innere, auf dem sonst bei einem Servoanschluss “Signal” liegt!  –  Und nur zur Erinnerung: Nicht mehr als 6V und, wenn’s geht, nicht verpolen!
.
T18MZ  -  Firmware
Die verwendete Version sollte 2.1.0 sein (“Editor 2.1.0″). Die 2.2.0 (aktuelle Version) hat einen Bug bzgl. der maximalen Alarmschwelle auf GPS-F1675/Distanz, die kann hier nur 500m sein, in der 2.1.0 sind es richtigerweise 5000m. Nun, 500mAh als höchstmögliche Alarmschwelle ist ein bisschen doof, oder? :)
.
Robbe Telemetry Box
Bzgl. derer gibt’s eine Besonderheit zu beachten:  Wir verwenden das Display GPS/Distanz für “mAh”. Für die T18MZ und die T14SG geben wir diesen Wert einfach in den entsprechenden Time Slot auf dem Bus. Die T-Box aber ignoriert diesen, errechnet Distanz stattdessen selbst. Nun muss JLog etwas tricksen, um die T-Box zu veranlassen, das in “Distanz” zu zeigen, was er will, “mAh”, wobei es trotzdem zu zeitweisen Abweichungen um bis zu 2 mAh kommen kann:
Die T-Box errechnet “Distanz” nach dem Satz des Pythagoras (rechtwinkliges Dreieck), Ihr wißt schon, die olle Kamelle aus der Schule, a²+b²=c², wobei “Distanz” die Hypotenuse ist, die längste Seite, und “Höhe” (==rpmRotor/10) und “GPS-Entfernung” (Entfernung Modell–Pilot, projiziert auf die Erdoberfläche) sind die beiden anderen Seiten. “Höhe” und ” GPS-Entfernung” stehen im rechten Winkel zueinander.
JLog macht nun Folgendes:  Er will ja “Höhe” als Drehzahl und “Distanz” als mAh individuell bestimmen können, muss eben nur beachten, dass die T-Box die Distanz selbst errechnet. Ergo dreht er an der GPS-Entfernung ständig so, dass “Distanz” als mAh richtig kommt und unter Berücksichtigung des gegenwärtigen Wertes für “Höhe”, was Rotordrehzahl/10 ist.  Damit er die GPS-Entfernung bestimmen kann, muss er wissen, was die Start-GPS-Position ist, die sich die T-Box merkte. Diese Position muss 0,0 sein!
Damit das funktionieren kann, bitte Folgendes beherzigen:
Bitte die T-Box möglichst vor JLog (vor dem Modell) anschalten. Der verwendete Empfänger R6308SBT (FASST® im Uplink, FASSTest® im Downlink ->T-Box) sendet nicht an die T-Box, solange er keinen Empfang vom Sender (FASST®) hat. Also bitte möglichst BEIDES vor JLog anschalten, Sender und T-Box!  –  Um das ganze Prozedere nicht zu kritisch zu machen, geht’s in den meisten Fällen auch so, weil JLog2 bis 10 Sekunden nach seinem Startup “GPS/Höhe” (rpmU/10) und auch “GPS/Vario” (Throttle/10) auf Null hält, damit die T-Box 0,0 als GPS-Startposition lernt. Es gibt in allen “Terminals” ein extra Display für Start- und momentane GPS-Position, in der T-Box muss man das explizit aktivieren für einen registrierten Sensor vom Typ “GPS”.  Hier kann man mit schnellem Blick vor Beginn des Fluges kontrollieren, ob die T-Box 0,0 als GPS-Start-Position “fraß”. Wenn nicht, dann SD raus aus JLog, T-Box aus/an, und SD mit Schmackes wieder rein in JLog, er resettet dadurch.
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.
.
T14SG
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.
.
Testwerte
Nun, das Testen der Displays kann man auch einfacher haben, nämlich mittels dieser Test-Firmware für JLog2. Folgendes sollte man zu sehen bekommen:
Vario 1/H Imot == 3152 (315.2A)
Vario 1/V Ibec == 35.2 (35.2A)
Vario 2/H Ubat == 504 (50.4V)
Vario 2/V Ubec == 8.4 (8.4V)
Vario 3/H extRPM/10 == 29513/10 == 2951 (29510rpm)
Vario 3/V extVoltage(extTemp1) == -19.6 == -1.9(Anzeige) (V(hier °C))
Temp1 tFET == 101°C
Temp2 tBEC == 82°C
Temp3 PWM == 95 (%)
Temp4 extTemp1(extVoltage) == -19.6 °C == -19°C(Anzeige)
GPS/H rpmUni/10 == 1873/10 == 187 (1870rpm)
GPS/V Gas/10 == 62/10 == 6.2 (62%)
GPS/speed == 423km/h
GPS/Distanz == 4832 (4832mAh) – Mit der T-Box: Eine Abweichung um 1..2mA ist möglich, Rundungsfehler auf beiden Seiten.
Die Testwerte alternieren mit Null im Sekundentakt (“wackeln”), sonst wäre das kein Test, weil die Terminals der Futaba-Telemetrie immer den zuletzt gesehen Wert speichern (“Hold”).
.
Alarming (hinzugefügt am Montag, 25.02.2013)
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:
..
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).
.
Last but not least
Die Firmwares und JLC5 finden sich im Download.
.
Traps und Pitfalls
Mal so locker gesammelt…
Empfänger R6308SBT, also für Nutzung der  Robbe T-Box: Normal-/Highspeed-Modus, Programmierung: Die LED muss grün 1x oder 3x blinken, wenn Telemetrie eingeschaltet sein soll!
T14SG mit Empfänger R7008SB: Solange nicht wenigstens die Empfängerspannung kommt, ist noch Dunkeltuten im Downlink (Telemetrie).  Das bitte beherzigen:
.. Die Bindung geht nur über den Sender mit LINK-Taste (im Sender), wenn Telemetrie funktionieren soll.
.. Die alte Methode (Link-Taste am Empfänger) der Bindung geht auch, aber dann ohne Telemetrie (p——)
.. WICHTIG: Zuerst LINK-Taste drücken und dann den Empfänger einschalten!

Danke, Rudi!
T18MZ:  Im Menü “Modulation” muss am Binde-Eintrag des Empfängers Telemetrie aktiviert sein. “D/L” am besten auf 0,1s setzen, Update der Sensordaten im Downlink (“D/L”) alle 100ms.  Ja und: “FASSTest 18CH” ist unser Mode, wenn der Empfänger ein R7008SB ist!
.
Am Rande
Man liest immer wieder: “S.BUS2 ist nur für Telemetrie.”
Das stimmt so nicht. S.BUS2 ist bidirektional, die Eierlegendewollmilchsau, und ohne die Servokanaldaten auf dem Bus würde die ganze Telemetrie sogar gar nicht funktionieren.Allerdings:  Mein Eindruck ist auch, dass zumindest die Anleitungen von Robbe suggerieren wollen, man solle den S.BUS2 nur für Telemetriesensoren nehmen.
Und, witzigerweise:  Der Empfänger R6308SBT sendet auf dem S.BUS2 auch S.BUS1-kompatible Servokanaldaten, obwohl er damit immerhin die Latenz der S.BUS2-Daten verdoppelt, von der Redundanz, dieselben Daten als S.BUS1 und S.BUS2 18CH, ganz zu schweigen.
Nachtrag:  Da hat man mich wohl falsch verstanden.. S.BUS1-Geräte gehören an den S.BUS1, S.BUS2-Geräte an den S.BUS2. Ich wollte hier keiner technischen Möglichkeit zum Mischen das Wort reden!
.
Servoruckeln…
Da man ja offenbar Randbemerkungen lieber liest als den eigentlichen Inhalt ;) , und da es ein gerade aktuelles Thema zu sein scheint:   Nun, ich habe keine T14SG. Es ist natürlich nicht ganz auszuschließen, dass die Firmware der T14SG beteiligt ist..  –  HF-Einstrahlungen? Nicht unmöglich, aber mit dieser Systematik über die Fälle?  –  (Apropos “Systematik”: Die vermisse ich etwas über die verschiedenen Fallschilderungen..)  –  Firmware des Empfängers? Nicht auszuschließen aber eher unwahrscheinlich hier.  –  Zu hoher Freiheitsgrad im Setup durch den User, “D/L” bis runter auf 0,1s, sprich, hohe Updaterate im Downlink bewirkt zu geringe Updaterate im Uplink? ….. Das kann ich testen, T18MZ mit D/L 2s bis 0,1s, im Servotest-Modus, Empfänger R7008SB, Servo (9075SB) an PWM/S.BUS/S.BUS2. Und vorsichtshalber auch Sensordaten auf den Bus, 18 Slots von 31, JLog2:  Kein Unterschied, da ruckelt nichts am Servo. Extra langen Zeiger auf die Servoscheibe geklebt, – kein Ruckeln.
Hmm… Eine Beteiligung der Firmware der T14SG ist wirklich nicht auszuschließen..  Siehe auch hier.

Die Kommentarfunktion ist geschlossen.