Der SPEKTRUM TM1000 “X-Bus” ist ein sog. I²C, auch TWI (Two Wire Interface) gennant. Er besteht aus den zwei Signalleitungen SCL und SDA, zzgl. Masse als Bezugspotential, natürlich. Auf dem X-Bus Connector gibt es zusätzlich Plus R/C Betriebsspannung, TM1000 als Quelle. JLog2.6, 2.5 kann hierüber mit Betriebsspannung versorgt werden. Dieselben Signale liegen in diesem Betriebszustand von JLog auch auf seinem Port “OPTions” an. Sofern man diesen Anschluss (Servosockel) der X-Bus Buchse vorzieht, muss JLog2.6, 2.5 natürlich anderweitig mit Betriebsspannung versorgt werden (siehe Anschlüsse und Stromversorgung). Ist der verwendete ESC ein KOSMIK oder JIVE, ist JLog bereits versorgt.
JLog2 hat denselben Port in Form eines Servoanschlusses, beschriftet als “Sensor/Alarm”. Seine Spannungsversorgung kann nur via den “JIVE” Port erfolgen.
.
Das Output Format (Telemetrietyp) muss hier nicht in JLC selektiert werden, es wird ja nicht COM verwendet.
Man kann aber neben dem TWI mit dem TM1000 zusätzlich und parallel etwas via COM ausgeben, in ein Unidisplay, eine JETIbox im textuellen Format, oder einen OpenFormat Livestream, z.B. für unmittelbare Anzeige in LogView.
Startup TM1000–JLog
Der TM1000 führt unmittelbar nach seinem Powerup einen Scan nach Sensoren (Adressen) durch, die an seinem X-Bus angeschlossen sind. Der ganze Scan dauert nur ca. 3,5 Sekunden. Besonders ungünstig ist, dass die Adressen in aufsteigender Folge abgefragt werden, jede zweimal im Abstand von 13 Millisekunden. Dadurch ist es so, dass im Bruchteil einer Sekunde alle relevanten, heute Sensortypen zugewiesenen Adressen, abgefragt sind. Hat der TM1000 eine angefragte Adresse nicht antworten gesehen, wird er den durch diese Adresse repräsentierten Sensor im nachfolgenden Betrieb nicht nach Daten abfragen. – Dieses Verfahren mag ja mit Horizon’s X-Bus Sensoren gehen, sie sind einfach genug, um rechtzeitig bereit zu einer Antwort zu sein. JLog ist aber nach seinem Powerup zunächst im Bootloader, und wenn eine SD Card detektiert ist, hat er darauf zu warten, dass diese ready wird, bevor er in deren Dateisystem nach einer evtl. vorhandenen Updatedatei schauen kann. Erst danach startet er die eigentliche Applikation, die dem Scan antworten könnte, – aber dann ist es längst zu spät. Ab einer bestimmten Charge hat JLog2, außerdem alle JLog2.5 und 2.6, einen modifizierten Bootloader. Dieser hält den Bus (TWI) und damit den Scan solange auf, bis JLog seine Applikation startete, bereit ist und die Sperre aufhebt. – Für Besitzer von JLog2 ohne neuen Bootloader wird daher die Option JSPEK (R²prototyping) angeboten. JSPEK enthält einen kleinen Microcontroller, der die Sperrfunktion übernimmt, die alle späteren JLog Bootloader selbst ausführen.
Während des Scans leuchtet die rote LED des TM1000.
Für den Powerup von TM1000 und JLog bedeutet das natürlich auch Folgendes: Erhält der TM1000 vor JLog Betriebsspannung, geht der Scan in’s Leere, was JLog als X-Bus Sensoren betrifft! Daher ist es schon sinnvoll, mit JLog2.6, 2.5 deren X-Bus Buchse zu verwenden, weil darüber auch Synchronität bei der Betriebsspannungaufschaltung entsteht.
Der TM1000 hat selbst ein paar Schnittstellen (Buchsen) zu “dummen” (atomaren) Sensoren, während die komplexeren (“intelligenten”) an sein X-Bus Interface angeschlossen werden. Da das ein TWI ist, können natürlich beliebig viele X-Bus-basierende und software-kompatible Sensoren (Horizon, 3rd party) angeschlossen werden, parallel, mechanisch meist kaskadiert ausgeführt, sog. “Daisy Chain”. So hat beispielsweise der Horizon GPS Sensor zwei X-Bus Buchsen, worüber er zusammen mit JLog in einer Daisy Chain an den TM1000 anschließbar ist. Selbstverständlich darf jede Adresse, jeder Sensortyp, nur einmal auf dem X-Bus existieren!
.
JLog als SPEKTRUM X-Bus Sensoren
21.02.2015: Vor Kurzem erschien eine neue Airware von Horizon mit Displays für neue Sensoren. Diese Displays sind besser geeignet für JLog als die bisherigen:
Current (Stromsensor)
ESC (neu)
Flight Pack (neu)
Rx Pack (neu)
Die erforderliche, momentan neueste Airware ist zum Beispiel die 1.07 für die DX9. Die gute Nachricht ist, dass diese Airware auch für die Sender DX7(G2) und DX6(G2) bereit steht. Dadurch sind diese Sender zum ersten Mal auch für Telemetrie mit JLog via TM1000 nutzbar. Momentan gibt es die neue Airware für die DX8 noch nicht. Mit einer DX8 nutzt man daher vorübergehend noch die bisherigen Displays, siehe zweiten Abschnitt.
In den Downloadern findet man JLog Firmwares für jeden unterstützen ESC-Typ nun zweimal für SPEKTRUM-Telemetrie, z.B. für den JLog2.6:Bzgl. des JLog2.5 und JLog2 ist zu beachten, dass sich diese Firmwares jeweils in den Downloadern für “konsolidierte Firmwares” finden!
Neu ist auch, dass die durch JLog dargestellten SPEKTRUM Sensoren nun keine Alarme mehr zum Sender schicken können. Alle Alarmschwellen (und gewünschte Signalisierungstypen) werden ausschließlich im Sender eingestellt. Zumindest, wenn man einen loggenden JLog hat (JLog2 oder 2.5 oder 2.6 als Enabling Type “F” oder “L”), sollte man trotzdem auch im JLC die Alarmschwellen einstellen. Grund: JLog loggt auch Alarme, was gut ist für forensische Zwecke.
Zunächst schaltet man die benötigten/gewünschten Displays zur Anzeige frei. “Rx Pack” benötigt man nur, wenn man einen CVS16 als “JLog-eigenen” Sensor betreibt (mit SPEKTRUM Telemetrie geht das nur mit JLog2.6):
Dann definiert man die gewünschten Alarmschwellen und Signalisierungstypen (Tone, Vibe, Voice, Tone/Vibe, Voice/Vibe). Außerdem kann ein wiederholender Voice Report auf ein Sensor Display aktiviert werden, und man kann einstellen, wie oft sich ein Voice Reort im Alarmfalle wiederholt.
Im “Current” Display wird man im allg. keinen Alarm auf den Strom setzen, man kann es aber, wenn man will:
Die Alarmschwellen im “ESC” sind selbsterklärend. Da sich der Motorstrom aus “Current” in “ESC” wiederholt, kann alternativ hier ein Alarm gesetzt werden. (Leider gibt es keine Alarmmöglichkeiten für weitere Subdisplays von “ESC”, BEC-Temperatur, BEC-Spannung und -Strom. Bzgl. der BEC-Temperatur behelfen wir uns auf andere Weise, s.u.)
Die von JLog gesendete Drehzahl ist rpmMotor. Wichtig ist, die Polzahl in JLC einzustellen, dafür aber NICHT im Setup von “ESC” im Sender! Will man statt der Motordrehzahl die Rotordrehzahl sehen, stellt man einfach sein Ratio (Untersetzungsverhältnis) in “ESC” im Sender ein, – z.B. wie im Screenshot 12.82:1 für ein einstufiges Getriebe mit 17Z Ritzel und 218Z Hauptzahnrad (Voodoo 600).
Der Motorstrom aus “Current” und “ESC” wiederholt sich auch in “Flight Pack“, weshalb alternativ auch hier ein Alarm auf ihn definiert werden könnte (wenn, dann aber insgesamt nur EINEN Alarm auf den Motorstrom setzen!). “Temperatur” ist die BEC-Temperatur, auf die wir in “ESC” keinen Alarm setzen können. Bzgl. eines ESC, der beide Temperaturen bereitstellt, FET und BEC, wird es i.allg. aufgrund der Wärmekopplung im ESC nicht so wichtig sein, auch auf die BEC-Temperatur eine Alarmschwelle zu setzen, – die powerFET-Temperatur ist da wichtiger. Wenn ich aber einen HV²BEC als “JLog-eigenen” Sensor an JLog betreibe (mit SPEKTRUM Telemetrie nur mit JLog2.6 mit extra Data Bus), dann ersetzen sich automatisch ein paar Daten aus dem ESC durch solche aus dem HV²BEC: Ubec (BEC-Ausgangspannung), Ibec (BEC-Ausgangsstrom), tBEC (BEC-Temperatur). Nun, ein HV²BEC kann sehr gut selbst auf sich aufpassen , wenn man aber will, kann man eine Alarmschwelle auf die BEC-Temperatur setzen.
Das Display (der SPEKTRUM Sensor) “Rx Pack” wird nur für Werte aus einem CVS16 verwendet. Betreibt man keinen CVS16 an JLog, macht es auch keinen Sinn, dieses Display im Sender zu aktivieren.
Das Display zeigt 3 Werte: “Current” in mA wird verwendet für OOB1, für die Nummer (1..16) der ersten Zelle im Zustand “out-of-balance”. Da der kleinste Max-Alarm 10(mA) beträgt, zeigen wir die Zellennummer *10 an, – 10, 20, 30, …, 160. Die zu defnierende Alarmschwelle beträgt daher IMMER 10mA. Sobald irgendeine Zelle den Alarmzustand OOB zeigt, erscheint ihre Nummer *10 im Subdisplay “Current” von “Rx Pack”. Sprich, der Displaywert ist mindestens 10, wenn er nicht Null ist. Somit schlagen wir zwei Fliegen mit einer Klappe: Wir bekommen den OOB Alarm und wir sehen wenigstens die Nummer der ersten Zelle, die OOB ist, im Display (*10).
In “Capacity” wird LCN ausgegeben, die Nummer der Zelle, die LCV (Lowest Cell Voltage) hat, und zwar “nativ”, also 1..16. Wir benötigen keine Alarmschwelle auf diesem rein informativen Display.
“Volts” zeigt LCV, Lowest Cell Voltage. Hier definieren wir eine Min-Alarm-Schwelle. (Nicht zu hoch ansetzen, 3.2V im Beispiel sind schon etwas hoch!)
Nun die Data Displays selbst:
Wie immer, Ubat aus dem ESC wird ersetzt durch TPV (Total Pack Voltage), wenn ein CVS16 betrieben wird und dieser sich im Pack Mode befindet (ein Cell Pack erkannt wurde). Die BEC-Werte, sonst aus dem ESC, werden mit einem HV²BEC am Data Bus (nur JLog2.6) durch Werte des HV²BEC ersetzt.
Atomare JLog-eigene Sensoren, – (ESC-externe) Temperaturen mit anlogem oder digitalen Sensoren, (ESC-externe) Drehzahl, Speed, C200, – können nicht an JLog angeschlossen werden, wenn die Telemetrie SPEKTRUM oder HiTec ist. Grund ist, dass der “OPT” Port von JLog bereits besetzt ist durch den I²C Datenbus mit dem TM1000 (X-Bus) bzw. den HiTec Empfänger. (Mit HiTec werden digitale Temperatursensoren stattdessen an “COM” unterstützt.) - Somit benötigen wir keine Displays für JLog-eigene Sensoren. (Evtl. werde ich später auch digitale Temperatursensoren an “COM” unterstützen, deren Werte in “Powerbox” oder “G-Force” ausgegeben werden.) “Speed” kommt aus einem analogen Differenzdrucksensor (eine Spannung), das ist eine Prandtl Sonde. Leider kann JLog an “COM” keine Spannung messen, nur an “OPT”, was durch die Telemetrie besetzt ist.
Noch ein Wort zu den Motorstrom-Displays: ”Current” zeigt den Wert nur ganzzahlig, ebenso “Flight Pack”, während “ESC” eine Anzeigeauflösung von 0.1A hat. “Current” rundet ab, “Flight Pack” rundet auf. Das würde dann zu dem Effekt führen, dass, wenn “ESC” 132.5A zeigt, “Current” 132A aber “Flight Pack” 133A zeigen würden. JLog rundet daher selbst auf für die Ausgabe in “Current”. Somit sind die Stromanzeigen wieder konsistent wie oben in den Screenshots: 133A, 132.5A, 133A.
Momentan haben wir noch zwei kleine Bugs in der neuen Airware:
Ziemlich unwichtig: Werte größer 1999 werden fälschlich mit einer “1″ in der Tausenderstelle angesagt.
Alarming: Wenn ein Alarm auslösender Wert innerhalb der Alarmbedingung bleibt, und ich habe ihn weggedrückt (CLEAR), dann wird kein anderer Wert desselben Sensors (Displays) einen Alarm triggern.
Beispiel: Ich fliege 10S, stelle aber für ESC Voltage die Alarmschwelle auf 50V. Das löst sofort aus, ich drücke es weg. Für tFET habe ich 85°C eingestellt. Momentan ist die Temperatur noch 70°C. Später erreicht sie 85°C und steigt darüber, – es gibt aber keinen Alarm, weil Voltage permanent in der Alarmbedingung hängt, und den Alarm drückte ich weg.
Ich bin mir sicher, dass Andy (Developer at Horizon) das bald fixen wird.
Die bisherigen Firmwares bleiben verfügbar in den Downloadern, bis Horizon die neue Airware auch für die DX8 bereitstellt:
JLog stellt mehrere Horizon SPEKTRUM X-Bus Sensoren dar, um wie üblich, leider auch hier notwendig, “fremde Displays” für seine Zwecke zu “mißbrauchen”. Das sind:
Current (Stromsensor)
PowerBox
GForce
(Die Spezialausführung “HTI” von JLog2.5 verwendet zusätzlich den Höhensensor. Der Airspeed Sensor wird durch JLog nicht verwendet, weil die Pins, die zum Anschluss eines Staurohrs SM#2560 benötigt werden, bereits durch das TWI (X-Bus) besetzt sind. Speed könnte nur vom Fremdsensor SM GPS-Logger abgelauscht werden (auch Höhe -> Höhensensor Display), aber nur GPS SOG (Speed Over Ground), das wurde aber inzwischen aus den JLog Firmwares entfernt.)
Current Sensor (0×03) Imot (A) (*1)
PowerBox (0x0A)
Akku1: Ubat 0.. 99.99 V
Akku2: Ubec 0.. 99.99 V
Kapazität1: rpmUni(Rotor) 0..65535 (rpm)
Kapazität2: mAh 0..65535 mAh
Sensoren (Displays) müssen zunächst im Sender freigeschaltet werden, außerdem bedarf es der Freigabe von Alarmfunktionen, teilweise des Setzens von Alarmschwellen. Es hängt vom obigen Sensortyp ab, ob der Sensor selbst Alarme senden kann, oder man Alarmschwellen auf seine Werte im Sender setzen muss.
Die Sensordisplay-Auswahl
Hinter jeder Ziffer stehen jeweils alle bisher nicht selektierten Sensortypen zur Auswahl. Im obigen Setup bleiben noch unselektiert: “dummer” Temperatur-/Drehzahl-/Spannungssensor an einem Spezialport des TM1000, Höhensensor, Airspeed Sensor, GPS Sensor. Für JLog müssen Stromsensor, PowerBox und GForce selektiert sein, alles X-Bus-basierende Sensoren, wie auch Höhe/Airspeed/GPS. Man klickt nun in einen selektierten Sensor hinein, um seine Anzeige freizugeben und auf ihn bezogene Alarme.
Current (Stromsensor)
.
PowerBox
.
GForce
Aufgrund dessen, dass in GForce nur auf “Z” eine Alarmschwelle definierbar ist, deren Wertebereich aber nicht ausreicht, gibt JLog tFET (ESC Endstufentemperatur) zweimal aus, in “Z” als °C-Betrag mal Nullkommavier, in “Zmax” 1:1 als °C-Wert. Um eine Alarmschwelle auf 85°C zu setzen, nimmt man also 0.4*85=34 im Alarm Setup auf GForce “Z” im Sender. Für das Visuelle erscheint die unmodifizierte Temperatur noch mal in “Zmax”, hier kann man aber leider keinen Alarm drauf definieren. (Auf “Zmin” können nur Alarme im negativen Wertebereich definiert werden.)
.
.
Eine DX7S ist leider nicht verwendbar, weil sie keine “PowerBox” kennt.
Das Output Format (Telemetrietyp) muss hier nicht in JLC selektiert werden, es wird ja nicht COM verwendet.
Bzgl. des JLog2.5 und JLog2 ist zu beachten, dass sich diese Firmwares jeweils in den Downloadern für “konsolidierte Firmwares” finden!
, wenn man aber will, kann man eine Alarmschwelle auf die BEC-Temperatur setzen.
Wie immer, Ubat aus dem ESC wird ersetzt durch TPV (Total Pack Voltage), wenn ein CVS16 betrieben wird und dieser sich im Pack Mode befindet (ein Cell Pack erkannt wurde). Die BEC-Werte, sonst aus dem ESC, werden mit einem HV²BEC am Data Bus (nur JLog2.6) durch Werte des HV²BEC ersetzt.
