Futaba S.Bus2

Anschliessen
Der Telemetrieanschluss des Empfängers wird mit dem Port “S.Bus2/S.Port” von JLog2.6/2.5 verbunden. Man verwendet dafür ein Servo-Patchkabel. Der rote Draht muss nicht gezogen werden, es wäre aber trotzdem “eindeutiger”, es zu tun. JLog kann über diesen nicht mit Betriebsspannung versorgt werden, stattdessen gibt er hier selbst eine Spannung von 3,3V aus. Diese wird z.B. verwendet, um ein angeschlossenes Unidisplay zu versorgen. Es schadet aber nicht, wenn hier die R/C-Spannung vom Empfänger erscheint, u.U. sogar HV, weil eine Diode in JLog dafür sorgt, dass Strom nur in eine Richtung fließen kann.
JLog2
JLog2 benötigt zusätzlich “JSend“, da die Signale des Busses invertiert sind.
Futaba S.Bus2, JLog registrieren am Sender/T-Box
Hier kommt nun zwangsläufig der Punkt, an dem man spätestens die in “Dokumentation” vollmundig deklarierten Grundsätze verlassen muss, was das Dokumentieren fremder Produkte betrifft. Die Manuals der FASSTest Fernsteuersysteme von Futaba versäumen es leider, deren Telemetriesystem zu erklären. Es gibt nur einen “Waschzettel” zu jedem Futaba Sensor dazu, der es aber nicht wirklich transparent macht, – zudem hat man den Zettel ja nicht, wenn die einzigen Futaba Sensoren diejenigen sind, die JLog emuliert. Gerade dieses notwendige Registrieren von Futaba Sensoren, bevor sie auf dem S.Bus2 platziert werden können, erfordert es aber, dem Anwender die spezifischen Prinzipien zu erklären, bevor er durch Fehlanwendung Kopfschmerzen erleidet. Nun.., als Support für ein Gerät, das 8 Telemetriesysteme unterstützt, kann ich mit Bestimmtheit sagen, dass diese “Kopfschmerzen” sehr verbreitet sind. Natürlich ist das auch ein Zeichen für den nach wie vor großen Freundeskreis der Futaba Systeme.
Das ist der “Manual-Ersatz“, bitte lesen Sie das, bevor Sie hier fortsetzen.
Das Registrieren von JLog am “Terminal”, Sender oder Robbe T-Box, – genauer gesagt, das Registrieren der 8 Futaba Sensoren, die JLog darstellt, – wurde ja im obigen Link bereits beschrieben.
.
JLog in den Telemetrie Displays
JLog registriert sich als 8 Futaba Sensoren, in der Reihenfolge
  • Robbe F1678 Stromsensor
  • Futaba SBS-01 RM/O Drehzahlsensor
  • 4x Robbe F1713 Temp.sensor
  • Robbe F1678 Stromsensor
  • Robbe F1713 Temp.sensor
(Warum “Robbe” und “Futaba” Sensor unterschieden? Robbe hat von Futaba eines reservierten Sensor-ID-Bereich für eigene Entwicklungen. Man kann feststellen, dass die wichtigsten Sensoren der Praxis IDs aus dieser Range haben. Well done, Robbe! Ehre, wem Ehre gebührt. )
Besetzt werden dabei insgesamt 12 Zeitschlitze. Ob diese fortlaufend sind (im Rahmen der in “Manual-Ersatz” genannten Regel der Aufteilung auf 4 Frames ´a 8 Time Slots), lag im Ermessen des Senders und hängt davon ab, ob zuvor schon andere Sensoren registriert worden sind. Im Allgemeinen, und natürlich, wenn JLog die einzigen Sensoren stellt, sind die Zeitschlitze fortlaufend den 8 Sensoren von JLog zugeteilt, und damit findet man auch die Displays der 8 Sensoren in der Reihenfolge ihrer Anmeldung.
  • (erster) F1678: “Current”==Imot, “Voltage”==Ubat, “Capacity”==mAh
  • SBS-01: RPM Rotor (Sensor im Sender auf “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)
Legende
Ubat == Antriebsspannung (V)
Imot == Motorstrom (A)
mAh == Gesamtverbrauch (mAh)
RPM Rotor == (auch “rpmUni” genannt) untersetzte Motordrehzahl ==Rotordrehzahl (UpM)
tFET == ESC Endstufentemperatur, also von deren FET Leistungstransistoren (°C)
tBEC == BEC Temperatur, wenn vom ESC geliefert, – vom HV²BEC, wenn angeschlossen/konfiguriert(JLC) (°C)
throttle == Gaswert aus einem ESC, wenn von dem geliefert (0..100%)
PWM == “internes Gas” eines ESC, wenn von diesem an JLog gemeldet (0..100%)
Ibec == BEC Ausgangsstrom, wenn vom ESC gemeldet, – vom HV²BEC, wenn angeschlossen/konfiguriert(JLC) (A)
Ubec == BEC Ausgangsspannung, wenn vom ESC gemeldet, – vom HV²BEC, wenn angeschlossen/konfiguriert(JLC) (V)
externe RPM == (auch “extRPM” genannt) von einem JLog-eigenen Drehzahlsensor (UpM)
Speed == Air Speed vom JLog-eigenen Sensor SM#2560 (km/h)
externe Temperatur#1 == (auch “extT1″ genannt) erster Wert von max. 3/5 JLog-eigenen Temp.sensoren (°C)
externe Spannung 0..12,8V == JLog als Spannungssensor. (V)  (Nur noch JLo2/2.5, demnächst auch in deren Firmwares abgeschafft.)
Cell Voltage Sensor CVS16:  Das Ausgeben von LCV (Lowest Cell Voltage) und LCN (Nummer der Zelle mit LCV, 1..16) in ein Display ist bisher nicht vorgesehen mit diesem Telemetrietyp. Alarme vom CVS16 via JLog, JLog’s Alarm auf LCV, werden natürlich auf den Ubat Alarm abgebildet.
—————————————————————————————————————————————————————-
27.7.2014/27.8.2015:  Es war einmal eine Sonderfirmware + extra JLC für einen Sonderwunsch, jetzt generell in allen Firmwares für JLog2.6: Wenn CVS16 konfiguriert: LCV4UBEC (Lowest Cell Voltage für Ubec):  Per JLC konfigurierbar wird im Display für Ubec (“Voltage” im zweiten Stromsensor) LCV (Lowest Cell Voltage) angezeigt, wenn CVS ein Cell Pack erkannt und dies an JLog gemeldet hat.  Leider lässt das Display von Hause aus nur 100mV Anzeigeauflösung zu, obwohl es mit 10x höherer Auflösung beschickt werden will. JLog gibt daher mit zusätzlichen *10 aus (Falschkommastellung), z.B. “37.6V” für 3.76V. Das Display bekommt somit zwar LCV in voller Auflösung, wie z.B. “3765″, aber es gibt immer nur eine Kommastelle seitens Sender/T-Box. Die max. erreichbare Auflösung ist 10mV, indem man Faktor 10 ausgibt.  –  LCN (Nummer der Zelle mit LCV) wird bisher auch weiterhin nicht in ein Futaba-Display gegeben.  –  Alle Alarme von CVS und JLog’s LCV-Alarm werden wie bisher nur auf das Ubat-Display gemappt, also 50,0V addiert im Alarmfalle.
—————————————————————————————————————————————————————-
Alarme
Das Thema wird hier ausgeführt, zusammen mit ein paar “Absonderlichkeiten” der Futaba Telemetrie.
Futaba’s Telemetrie ist eine derjenigen, in denen ein Sensor keine Alarme übermitteln kann. Stattdessen bildet das Terminal (Sender, T-Box) Alarme auschließlich selbst, indem man auf jeden Displaywert Alarmschwellen setzen kann. Viele Anwender lieben das, dass man es am Sender einstellen kann, obwohl es eigentlich viel besser ist, wen ein Sensor es tun kann. Grund ist, dass nur der Sensor Alarme in Abhängigkeit vom Betriebszustand aktivieren kann, der Sensor als State Machine. Nun mag das für einen Standard-Futaba-Sensor nicht so wichtig sein, für JLog ist es das schon, denn schließlich monitort er Geräte, ESCs.
Ein’s kommt zum anderen, in Futaba Telemetrie leider ausgeprägt, und schon haben wir die Chance auf “Zombie Alarme” bzw. “Alarm-Belästigung”. 1) Ein Unterspannungsalarm rappelt natürlich, sobald der Wert unter der definierten Schwelle erscheint. Dass er von Anfang an, seit Erstverbindung zum Empfänger, Null war, interessiert den Sender dabei nicht.  2) Eine erreichte (überschrittene) Kapazitätsalarmschwelle (mAh) führt zu Daueralarm aus diesem Wert heraus.  3) Erfährt der Sender kein Update mehr vom Empfänger (Verbindung weg), dann friert alles auf den zuletzt empfangenen Werten ein (Hold), evtl. bestehende Alarmbedingungen damit auch.  4) Es ist nicht vorgesehen, die Ausgabe eines aktiven Alarms am Terminal zu quittieren (zu stoppen).
Daher kann JLog per Konfiguration auf Umwegen doch zum Alarmsender gemacht werden für fünf der von ihm gesendeten Daten:
erster 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 zu addieren, geht leider nicht (100 wären gut gewesen), obwohl das Display auch über 600 kann, weil die Alarmschwelle nicht hoch genug dafür einstellbar ist.
Wer das nicht will, setzt eines Unterschreitungsalarm im Sender und keinen im JLC, muss dann aber mit dem Zombiealarm bei Null leben, je nach Setup des Modells und den Anwendungsgewohnheiten (Telemetrie läuft evtl. weiter, wenn Antriebsakku abgeklemmt).
Leider kennt “Voltage” eines F1678 keine negativen Werte , wohl aber “Current” und “Capacity (mAh)”. Sehr praxisorientiert…
erster F1678-Capacity– mAh:  Alarmschwelle im JLC setzen, und im Sender auf Unterschreiten von Null. JLog gibt die momentanen mAh mit negativem Vorzeichen aus im Alarmfalle. Darüber wird auch ein Pulsen des mAh-Alarmes durch JLog gemacht, 5s aktiv, dann 20s Pause, dann wieder 5s aktiv. Somit kein Daueralarm, wie es der Sender allein machen würde. Ist Gas<10% (PWM<10% beim KOSMIK), dann wird der Alarm  gar nicht mehr ausgegeben (der Motor steht), erst wieder, wenn Gas>=10% (bzw. PWM>=10%).
zweiter F1678-Voltage- Ubec:  Im JLC hat man den “Ubec Dip Alarm” aktiviert. Unterschreitet Ubec, vom ESC oder von einem HV²BEC, den Startwert um einen bestimmten Betrag für eine bestimmte Mindestzeit, dann signalisiert JLog Alarm dadurch, dass er 50V auf den Momentanwert addiert. Im Sender setzt man einen Überschreitungsalarm auf 20V oder so, jedenfalls kleiner/gleich50V.
Man hat also bzgl. der beiden ersten Werte die Wahl.  –  mAh: Entweder man setzt die Alarmschwelle in JLog’s JLC und setzt die im Sender auf Unterschreiten von Null (zweites Alarm Setup Display auf F1678 “Capacity” in der T14SG), oder man setzt keine Alarmschwelle auf mAh im JLC (Null mAh) und macht es auf herkömmliche Weise im Sender, Überschreitungsalarm auf den Wert seiner Wahl.  –  Ubat: a) Man setzt einen eine Alarmschwelle im JLC und im Sender auf ÜBERschreiten eines Wertes, der größer ist, als die je erreichbare Spannung, Max-Spannung + 50V.  b) Man setzt keine Schwelle auf Ubat im JLC (Null Volt) und macht es herkömmlich im Sender, Unterschreitungsalarmschwelle, geeigneter Spannungswert.
zweiter F1678-Capacity- Speed:  Wenn dieser JLog-eigene Sensor, SM#2560, konfiguriert ist, erscheint im Display der Speed-Wert (km/h), ansonsten extRPM, JLog-eigener Drehzahlsensor. In JLC sind zwei Alarmschwellen setzbar, MinSpeed (Stall Speed) und MaxSpeed. Für MaxSpeed setzt man eine Überschreitungsalarmschwelle im Sender. Für Stall Speed setzt man die Alarmschwelle im Sender auf Unterschreiten von Null. JLog gibt dem Wert ein negatives Vorzeichen, wenn Stall Speed Alarm vorliegt.  –  Das hat wieder den Zweck, “Zombie Alarme” zu vermeiden. JLog gibt die MinSpeed-Alarmschwelle erst frei, wenn die Geschwindigkeit einmal diesen Wert überschritten hatte. Der Sender hingegen würde sofort einen Alarm erzeugen, bevor man losgeflogen ist.
fünfter F1713:  Normalerweise erscheint hier die Temperatur vom ersten JLog-eigenen Temperatursensor. Die bisherigen Firmwares von JLog2 und JLog2.5 erlauben aber auch, statdessen einen Spannungssensor im JLC zu konfigurieren. Gemessen werden 0..12,8V, wozu der Anwender aber extern an JLog einen Spannungsteiler (2 Widerstände) 1:5 anschließen muss. Im JLC kann man eine Alarmschwelle auf das Unterschreiten einer Minimalspannung setzen. Bei Vorliegen der Alarmbedingung gibt JLog dem Wert ein negatives Vorzeichen. Im Sender setzt man eine Alarmschwelle auf Unterschreiten von Null. Die Spannung wird ohne die eine Kommastelle ausgegeben, z.B. 128°C für 12,8V, -45°C bei Unterspannungsalarm, Schwelle steht im JLC auf 4,5V.  –  Wenn in Q2/2014 die Firmwares von JLog2.5 und 2 konsolidiert werden, abgeglichen gegen die von JLog2.6, dann wird dieser Spannungssensor aber wegfallen. Stattdessen könnte man dann einen CVS16 einsetzen als Spannungssensor.
Natürlich kann man in den beiden obigen Fällen auch wieder einfach keine Alarmschwelle im JLC definieren (Null setzen), stattdessen alles mit Alarmschwellen im Sender machen, auf die herkömmliche Weise, – natürlich mit dem Nachteil der Chance auf “Zombie Alarme”. Dasselbe gilt für Sonderalarm #3 auf Ubec, das ginge natürlich auch rein im Sender, in JLC wird “UbecDIp Alarm” (Checkbox) nicht aktiviert.
Alle anderen von JLog gesendeten Daten werden herkömmlich behandelt, man setzt auf einen Wert eine Alarmschwelle im Sender, oder man macht es eben nicht. Das heisst auch, dass andere im JLC definerbare Alarme nicht zum Sender signalisiert werden (ist ja eigentlich auch nicht möglich), sie werden aber von JLog geloggt.
Noch ein Hinweis:  Wie bereits ausgeführt, frieren Werte ein, wenn der Sender den Rückkanal des Empfängers verliert. Leider gibt es auch keinen generellen Alarm bei Verbindungsverlust. Man kann aber die Rx-Spannung, – der Empfänger ist immer selbst ein Sensor, sendet seine Betriebsspannung in Time Slot #1, alternierend mit der Spannung an seinem ext. Spannungssensor, – dafür benutzen, um einen Alarm bei Verbindungsverlust zu bekommen:  Einen Alarm auf die Rx-Spannung sollte man im Sender eh setzen, bei Unterschreiten eines Wertes der eigenen Wahl. Im Gegensatz zu allen anderen Sensorwerten geht dieser auf Null, sobald kein Update durch den Empfänger mehr erfolgt.
Sender:  Beim Binden des Empfängers muss Telemetrie explizit angeschaltet werden. “DL” (Delay) sollte nicht kleiner als 0,5 Sekunden gewählt werden. Es scheint einen Design Bug in Empfänger- oder Sender-Firmware zu geben, der sonst dazu führen kann, dass zu häufig übertragene Telemetriedaten im Downlink zu hohen Update-Latenzen der Steuerdaten im Uplink führen (Servo-Ruckeln).
Beachten Sie auch das:
Telemetry is available only in the FASSTest 14CH mode. (12CH mode displays only Receiver battery voltage and extra battery voltage.)
Die Tatsache, dass man die Empfängerspannung per Telemetrie sieht, ist also noch kein Zeichen dafür, dass das Setup im Binden des Empfängers an den Sender und des Senders selbst richtig ist, man Daten von Sensoren wie JLog am S.Bus2 Port des Empfängers per Telemetrie erwarten kann.
Es ist inzwischen schon ein alter Hut, daher nur der Vollständigkeit erwähnt:
Der Empfänger R7003 ist vor allem als S.BUS-Empfänger konzipiert, man kann daher sogar mehrere S.BUS bzw. S.BUS2 Ports definieren. Leider hat die Hardware einen Design Bug, was Rückwirkungen zwischen den S.BUS Ports bewirkt, S.BUS auf S.BUS2 (keine Telemetrie), aber auch der S.BUS für sich kann gestört werden. Das ist ein Sicherheitsrisiko, könnte die via S.BUS laufenden Steuerfunktionen beeinträchtigen.
Abhilfe schafft ein Pulldown-Widerstand von ca. 5,6 KiloOhm auf dem S.BUS Port, also zwischen Signal und Masse.
Inzwischen gibt es eine modifizierte Version des R7003 (interner Pulldown), erkennbar an einem Goldpunkt, mit dem der Empfänger markiert ist.
—————————————————————————————
So wird es evtl. in Zukunft aussehen, so sieht es seit geraumer Zeit auf einem anderen Gerät unserer Entwicklung aus (ungleich JLog2.x):
JLog stellt dann nur noch 6 statt bisher 8 Sensoren dar, dafür 16 Displays, 16 statt bisher 12 Time Slots belegt. Ziel und Effekt ist: 1. besser zu den Meßwerten passende Maßeinheiten, 2. thematisch klarere Ordnung und Zuordnung zu Sensorik hinter JLog.

Die Kommentarfunktion ist geschlossen.