JLog2 + SPEKTRUM

SPEKTRUM-Telemetrie, jedenfalls reichweitenmäßig ernst zu nehmende, basiert ausschließlich auf dem TM1000. Das ist ein Gerät mit eigenständiger HF-Strecke zum Sender als Telemetrieterminal, die angeblich mit dem Empfänger koordiniert sendet (hoffentlich), zumindest gäbe es die Möglichkeit dazu über die DATA-Verbindung zum Empfänger. Der TM1000 hat ein paar Schnittstellen zu “dummen” Sensoren, darüber hinaus ein “X-Bus” genanntes Interface für weitere, “intelligente” Sensoren. Der “X-Bus” ist ein I²C Bus.
Sensoren, die des TM1000, die am Bus des TM1000 (“X-Bus”) finden verschiedene Displays im Sender als empfangendes Terminal. Leider macht die Ausführung in den Firmwares der Sender einen etwas systemlosen Eindruck: Die Displays der Sensoren sind teilweise gruppiert, als “intelligenter” (X-Bus) Sensor “PowerBox”, z.B., teilweise aber auch “vogelfrei” als Display eingebaut. Ähnlich sieht es mit Alarmen aus:  Zum Teil muss der Sensor Alarme auslösen, im Sender können keine Alarme auf Sensordaten definiert werden, und teilweise ist es genau andersherum. Was besonders nervt, ist, dass nicht jede Sender-Firmware jeden Sensor unterstützt, Displays für ihn bereit hält. Beispielsweise gibt es den Sensor “JetCat” nur in der DX10t, und die DX7s kennt “PowerBox” nicht. (“PowerBox” wird durch JLog2 genutzt!)
Natürlich ist hier wieder mal “Mißbrauch von Datendisplays” angesagt für einen 3rd Party Multisensor wie JLog2. Es gibt keinerlei Flexibilität im System, um Displays, Maßeinheit, Wertebereich, Name, Alarmbereich, definieren zu können, wie es eh nur mit Multiplex M-Link (Multiplex Sensor Bus) und vor allem mit JETI EX der Fall ist. Das fällt “glücklicherweise” nicht so in’s Gewicht, weil das System bisher nur einen “dummen Alarm” kennt, ein- und denselben für alles, Piep Piep, keine differenzierten Alarmtypen, keine Sprachausgabe.
JLog2 findet nun seine Displays in 3 SPEKTRUM Sensoren:
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
G-Force (0×14)
X-Axis: 0..99.9 “Gas (%)
X-Axis Max: 0..99.9 “PWM (%)
Y-Axis: 0..99.9 “Ibec (A)
Y-Axis Max: 0..99.9 “Ibecmax (A)
Z-Axis: 0..99.9 “tFET *0.4 (°C)
Z-Axis Max: 0..99.90 “tFET (°C)
Z-Axis Min: 0..99.90 “tBEC (°C)
(Nun kommen die miesesten Screenshots der Welt. )
Bevor sich jemand in’s Bockshorn jagen lässt: Sensoren müssen erst im Setup des Spektrum-Senders eingeschaltet werden (Display – Strom, PowerBox, G-Force)! Das geht erst, wenn der TM1000 mit dem Sender gebunden ist. Binden: TM1000 am Data-Port des Rx, Button am TM1000 drücken und halten, Saft an Rx anlegen, TM1000 wird via Data-Port versorgt. Ein Satellit, wenn vorgesehen, sollte mit dem Rx verbunden sein. Sender Einschalten und in den Bind Mode. Abwarten, bis alles gebunden. Alles ist gut, wenn “—– A” im Stromdisplay sich in “0 A” verwandelt.
Alarm Setup

“Powerbox”
Die Alarme auf Ubat, Ubec (Dipalarm) und mAh werden in JLC gesetzt, im Sender werden die Alarme nur freigegeben und der Alarmtyp gewählt. Im Sender können keine Alarmschwellen gewählt werden.
Das Alarmdisplay, was im Sender hochpopt im Alarmfalle, zeigt keinen Wert für das auslösende Datum. Es erscheint immer nur die momentane Rx-Spannung.
“G-Force”
Dieser Sensortyp kann selbst keine Alarme melden. Stattdessen wird im Sender, für den Sensor “G-Force”, die Alarmschwelle eingestellt und der Alarmtyp gewählt. Ein Alarm kann nur auf “Z Axis” gesetzt werden, als “Z Max” und “Min”, – wir nehmen hier “Z Max”, positive Werte. Der Wertebereich beträgt aber nur 0..40.0(g), daher wird auf “Z Axis” von JLog tFET mal Nullkommavier °C (tFET *.4 °C) geliefert. Wir stellen also z.B. +34.0g ein, um bei Erreichen/Überschreiten von 85°C einen Alarm zu erhalten.
Das Alarmdisplay, was im Sender hochpopt im Alarmfalle, zeigt als Wert also tFET *0.4, im Beispiel “+34.0g”. Es erscheint immer auch die momentane Rx-Spannung in der ersten Zeile des Alarmdisplays.

.
JLog2 + TM1000
Es gibt ein Timing-Problem zwischen JLog2 und dem T1000 beim Startup, also bei Poweron:
Der TM1000 beginnt unmittelbar nach seinem Einschalten, den X-Bus nach Sensoren zu scannen, indem er eine Range von I²C Adressen abfragt. Leider tut er das auch noch aufsteigend, die möglicherweise besetzen Adressen kommen also zuerst ran. JLog2 braucht dafür zu lange im Bootloader, denn der mountet erst das Filesystem der SD und durchsucht sie nach einem möglichen Updatefile. Bevor er dann die Applikation, den eigentlichen JLog gestartet hat, ist seitens des TM1000 schon alles vorbei. Der TM1000 wird fortan nur Sensoren auf dem X-Bus abfragen (er ist Busmaster), die während des Scan anworteten.
Nun gibt es eine einfache Möglichkeit, den Scan des voreiligen TM1000 aufzuhalten, nämlich, indem man die Bus-Leitung “SCL” des X-Bus == I²C auf Low (GND) zieht, bis man bereit ist, zu antworten. Nur muss das im Bootloader passieren, und der wird nur einmal und mit Hilfe spezieller Hardware (Programmer) geflasht, bevor ein JLog zur Auslieferung kommt. Jeden “SPEKTRUM-willigen” JLog erst heimzurufen, um ihm einen angepassten Bootloader zu verpassen, kann nicht die Lösung sein. Zukünftige Chargen des JLog2 bzw. sein geplanter Nachfolger JLog3 werden das im Bootloader haben, für bereits verkaufte JLog2 braucht es aber eine andere Lösung.
Diese Lösung heißt “JSPEK“, demnächst im Shop bei MHM Modellbau. JSPEK sitzt zwischen JLog2 und TM1000 und macht das, was der Bootloader eines JLog2 u.U. noch nicht implementiert hat, er bremst per SCL den TM1000 nach dem Start für ein paar Sekunden aus. Wichtig ist, dass dieses Bremsen zum richtigen Zeitpunkt erfolgt, TM1000 und JLog2+JSPEK müssen also zum selben Zeitpunkt eingeschaltet werden, ihre Betriebsspannung bekommen. Die “Synchronisation” zwischen JSPEK und JLog2 ist dadurch gewährleistet, dass JSPEK JLog aus seinem Spannungsregler mit 4V versorgt, er macht ihn dadurch auch gleich HV-fähig.  –  Hier im Einsatz mit dem JIVE, hier mit einem Castle Creations ESC mit Castle Link Live, wobei auch JCC benötigt wird.
Zwischenzeitlich, bevor JSPEK bei MHM im Shop erscheint, flashe ich Eurem JLog2 den geänderten Bootloader auf, wenn Ihr mir den zuschickt mit einem beschrifteten (Empfänger/Absender) und frankierten kleinen Luftpolsterumschlag anbei.  –  Die zuletzt gefertigte Charge des JLog2 hat bereits den neuen Bootloader. Auf so einem JLog2 findet man auf dessen Rückseite einen Aufkleber mit dem Schriftzug “SBL3SPEK”.
Die Meldung des JLC, “Sie benötigen JSPEK”, bezieht sich natürlich nur auf JLog2 ohne geänderten Bootloader!
.
Um zum Test auch Daten in’s Display bekommen zu können, ohne Kopf und Kragen mit dem scharfen Heli in der guten Stube riskieren zu müssen, gibt es diese Test-Firmware, die Test-Daten sehen so aus:
Imot==372A
“PowerBox”
Ubat==39.65V
Ubec==8.54V
RPMuni==1045mAh (rpm)
mAh==3425mAh
“GForce”
throttle==87.0g (%), pwm==99.9g (100%)
Ibec=15.6g (A), Ibecmax==32.1g (A)
tFET*0.4==35.6g (°C), tFET==89.00g (°C), tBEC==63.00g (°C)
Werte, die mit einem Alarm belegt werden können, rot (JLog erzeugt Alarm, im Sender Alarmtyp zuzuweisen/Alarm enable) und grün (Alarmschwelle im Sender zu setzen, ebenso Alarmtyp/Freigabe).
In den Testwerten sind in der “PowerBox” Alarme für: Ubat und mAh.
Natürlich kann man, wenn man will, grün nach eigenem Gutdünken ausweiten, in dem Rahmen, in dem der Sender weitere Möglichkeiten kennt, auf Telemetriewerte Alarmschwellen zu setzen.
.
Was eigentlich noch fehlt:  JLog-eigene Sensoren, ext_t1..5, ext_rpm, speed (evtl. als “Airspeed” Sensor)
Für ext_t1..5 und ext_rpm haben wir nur keine Spektrum-Sensoren mehr, da der “JetCat” Sensor nur in den “dicken” Sendern gekannt wird.
.
Last but not least
Relevante JLog2 Firmware der neuen Ordnung “Series 4″ finden sich im Download, sowieso der zugehörige Konfigurator JLC5.

Die Kommentarfunktion ist geschlossen.