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” 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
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.