Registrieren

Wie erst jetzt bemerkt, enthalten die Hauptmanuals der Fernsteuersysteme von Futaba kein erklärendes Wort zur Telemetrie. Nur in den Minimanuals der Sensoren findet sich etwas. Wie die allgemeine Praxis und die mit JLog als Futaba Sensor beweist, reicht das ganz offenbar nicht aus, um dem Telemetrie-Anwender das Wissen zu vermitteln, was ihn vor Frust bewahrt.
Zunächst muss man das Prinzip verstehen, – hier geht’s nur um das Registrieren:

Futaba’s Telemetrie verwendet einen Bus für alle Sensoren, S.BUS2. Der Bus ist eine protokollarische Erweiterung des S.BUS, hierauf senden auch Empfänger die Servokanäle, und andere Busteilnehmer wie Gyros können auch Servos ansteuern.

Sensoren senden ihre Daten in Zeitschlitzen (Time Slots). Es gibt 32 Slots, wobei der erste Slot immer vom Empfänger beansprucht wird, in ihm sendet der Empfänger Empfängerspannung und externe Spannung (optionales Sensorkabel am Empfänger) auf den Bus. Darauf hört im Moment niemand, aber vielleicht zukünftig ein Flight Recorder.

Da also Daten von Sensoren nicht reihum abgefragt werden, sondern unaufgefordert von diesen in Zeitschlitzen zu platzieren sind, muss es eine koordinierende Stelle geben, die Slots an die Sensoren vergibt, damit die verschiedenen Sensoren nicht kollidieren auf dem Bus. Diese Stelle ist der Sender bzw. Robbe’s T-Box.

Daher muss sich jeder Sensor erst am Sender/T-Box registrieren, er bekommt dabei seine Slots zugewiesen.
Das Registrieren erfolgt, indem man das S.BUS2 Kabel des Sensors in den S.BUS Anschluss (“S.I/F”) des Senders/T-Box steckt und im Sender/T-Box das Register-Menü verwendet. Die Sender versorgen dabei den Sensor nicht mit Spannung, das muss man via Y-Kabel aus einer eigenen Quelle tun, nur Robbe’s T-Box kann den Sensor beim Registrieren mit Spannung versorgen. (FYI: Das Registrierungsprotokoll ist völlig anders als das des S.BUS2.)

Auch das Terminal, nämlich Sender oder T-Box, hat ein Informationsbedürfnis. Es muss nicht nur wisssen, welche Slots, und damit welche Daten, zu welchem Sensor gehören, es muss auch wissen, wie es die Daten zu interpretieren und darzustellen hat (Wertebereich, Kommastellung, Maßeinheit), welche Alarmschwellen anwendbar sind im Terminal, welche Voice Files (Sprachausgabe) auf die Daten eines Sensors zu mappen sind.

Das lernt der Sender/T-Box beim Registrieren, indem sich der Sensor identifiziert anhand einer bekannten, sensortyp-bezogenen ID. IDs werden von Futaba ausgegeben, je Sensortyp eine. Die Firmware von Sender/T-Box muss die IDs auch kennen, sagen sie ihm doch, wieviel Slots jeder Sensortyp (jede ID) benötigt und welche Daten darin zu erwarten sind.
Außerdem hat jeder Sensor eine Seriennummer, die er beim Registrieren an Sender/T-Box mitteilt. Das hat den Zweck, dass der Anwender später anhand der Sensordisplays Sensoren unterscheiden kann, die demselben Typ angehören. Auch der Sender/T-Box verwendet sie bei evtl. Umorganisieren von Slot-Zuweisungen.

Die Slot-Zuweisung erfolgt also durch den Sender/T-Box an einen Sensor, sie muss ergo an JEDEN Sensor erfolgt sein, der später am Verkehr auf dem S.BUS2 des Empfängers teilnehmen will! Der Sender/T-Box speichert das für sich. Auch jeder Sensor speichert sich die Slot-Zuweisungen, logischerweise.

Daraus folgt nun, dass man keine einseitigen Setup-Veränderungen vornehmen darf, sprich, nicht im Sender Zuweisungen löschen oder verschieben, ohne dass ALLE beteiligten Sensoren davon erfahren, indem sie re-registriert werden am Sender/T-Box! Beachtet man das nicht, produziert man Anarchie und die Wahrscheinlichkeit dafür, dass Sensoren auf dem S.BUS2 im praktischen Betrieb in den Zeitschlitzen kollidieren. Sender/T-Box verstehen die betreffenden Sensoren dann nicht mehr.

Wenn man weiß, was man tut, reicht es, den Sensor zu re-registrieren, dessen Slots man im Sender/T-Box verschob, aber eben nur die Slots DIESES Sensors. Nicht mehr vorhandene Sensoren sollte man natürlich löschen, bevor man einen anderen Sensor registriert. Dasselbe, wenn eine Registrierung teilweise schief ging, und man sie wiederholen will.
Wichtig ist nur das Prinzip:  Was der Sender/T-Box bzgl. der Slot-Zuweisungen eines Sensors weiß, sollte auch der Sensor wissen können, und das kann nur gewährleistet werden, wenn der Sensor bei Veränderung der Zuweisungen im Rücken des Senders steckte. Daraus folgt: Möglichst alles per Auto-Zuweisung machen.

Die Sensoren stehen in einer Beziehung zum Sender, zum gewählten Modellpeicher in diesem Sender, nicht zum Empfänger, der ist nur der “Transporteur”. Da immer die letzte Slot-Zuweisung an einen Sensor für diesen selbst wirksam ist, heißt das auch, dass ich einen Sensor nicht einfach von einem Modell in ein anderes setzen kann, wenn nicht die Sensor-Zusammenstellung identisch ist und alle Sensoren in derselben Abfolge am Sender einer Auto-Zuweisung unterzogen wurden. Kann ich solche identischen Zuweisungskonstellationen nicht gewährleisten, bleibt ein Sensor an seinen “konfigurativen Dunstkreis”, an das eine Modell gebunden.

Futaba/Robbe trägt leider selbst noch ein bisschen zu Verwirrung beim Anwender bei:  Einige derer Sensoren haben im Auslieferungszustand schon eine Default-Slotzuweisung. Das heisst, sie funktionieren auch ohne Registrieren, sofern man im Sender/T-Box, sozusagen “offline zum Sensor”, manuell die benötigten Slot-Zuweisungen vornimmt. Mit einigen 1-Slot-Sensoren geht das besonders einfach.  -  Das bedeutet aber auch, dass es nicht mehr funktionieren wird zumindest dann, wenn ich einen zweiten Sensor dieses Typs auf den Bus stecke, denn der hat ja die identische Default-Slotzuweisung. Auch mit anderen Futaba/Robbe-Sensoren könnte das passieren, wenn ihre Default-Slotzuweisung sich mit anderen Sensoren überlappt. Mit 3rd-Party-Sensoren, wie z.B. UniSens-E und Jlog, würde es mit hoher Wahrscheinlichkeit zu Kollision kommen, denn sie nehmen ja nicht an Futaba’s “Default Program” teil.
Die Qintessenz hierzu ist daher: Immer registrieren!

Zusatzinformation:  Wer sich nun wundern sollte, warum bestimmte manuelle Slot-Zuweisungen für einen Sensor im Sender/T-Box abgewiesen werden oder warum Slots nach Registrierung frei blieben:  Ein kompletter “Datendurchgang” auf dem S.BUS2 besteht aus 4 Blöcken (Frames). In jedem Frame gibt es 8 Slots für Sensoren, im ersten nur 7, weil der erste Slot vom Empfänger besetzt ist. Nun gibt es die Regel, dass ein Sensor seine Slots (1, 3, bis zu 8) immer nur in den Grenzen eines 8-Slot-Frames haben darf.

—————————————————————————————————————————————

JLog Registrieren

Einen Sensor “JLog” als ID gibt es bis dato nicht, er kann also nur Sensoren bekannter ID (Futaba/Robbe) “benutzen”, um seine relativ vielen Daten in die Telemetrie zu senden.
JLog ist daher ein “Futaba/Robbe Multi-Sensor”, er ist gleichzeitig, in dieser Reihenfolge beim Registrieren:

 F1678 – SBS-01 – F1713 – F1713 – F1713 – F1713 – F1678 – F1713

also 8 Sensoren insgesamt, die ALLE registriert werden wollen!

Im Gegensatz zu anderen Futaba oder Futaba-kompatiblen Sensoren schaltet JLog nicht selbst vom S.BUS2 Protokoll auf das Registrierungsprotokoll um, das muss man zum Registrieren im Konfigurator JLC tun:

Dort gibt es einen Knopf R, wenn S.BUS2 als Telemetrie selektiert ist, – den drückt man, und er wird rot (R).

JLog ist jetzt im Register Mode, sobald er diese Konfiguration von der SD gelesen hat, – das passiert mit seinem nächsten Start.

Wichtig ist nun, dass dieser nächste Start erst dann und nur zu dem Zweck des Registrierens geschieht. Er löscht nämlich nach dem Start, bevor er in den Register Mode geht, selbstständig das entsprechende R Flag aus der Config-Datei wieder heraus, sodass er mit dem darauf folgenden Start NICHT mehr im Register Mode ist. Also JLog nicht zwischendurch, vor dem Registrieren, noch mal unnötig starten! Tut man es doch, muss man erst wieder im JLC den Knopf R in R verwandeln.

Das Servo Patch Kabel vom S.BUS2 Port von Jlog geht zum Registrieren in den S.BUS Anschluss des Senders/T-Box. An die Stromversorgung von JLog für den Registrierungsvorgang denken!

Im Register Menü des Sender bzw. der T-Box betätigt man nun 8x (!!!) Register, es handelt sich ja bei JLog um 8 Futaba/Robbe Sensoren, s.o. Beim neunten Register-Versuch wird eine Fehlermeldung vom Sender kommen, für JLog ist das Registrieren abgeschlossen.

Bricht man das Registrieren vor dem achten Sensor ab, löscht JLog alle bis dahin vom Sender/T-Box erhaltenen Slot-Zuweisungen!  Das passiert auch, wenn man versehentlich den R Knopf drückte im JLC und JLog mit dieser Konfiguration startete, obwohl man gar nicht registrieren wollte.

Zuweisungsdaten werden nicht in “CONFIG.txt” auf der SD gespeichert, JLog merkt sie sich nur im Prozessor (im EEPROM). Das soll Konfusion durch eine dritte beteiligte Instanz ausschließen, das wäre die Config-Datei auf einer SD.

Letzte Handlung ist natürlich, nach erfolgreichem Registrieren das Servo Patchkabel, von JLog’s S.BUS2 Port kommend, nun in den S.BUS2 Port des Empfängers zu stecken, bzw. irgendwo auf den S.BUS2, den man z.B. durch Y-Kabel aufspannt.

Man sollte natürlich vor dem Registrieren schauen, dass der Sender noch genügend freie Slots kennt. Die 8 Sensoren, die Jlog darstellt, benötigen insgesamt 12 Slots. Dabei ist dieses oben erwähnte 8-Slot-Limit zu beachten: Wenn in einem Frame noch 1 Slot frei ist, wird er genommen, wenn der nächste zu registrierende (Teil-)Sensor nur einen Slot benötigt, wie SBS-01 und TEMP125. Die 3 Slots eines CURR-1678 aber wollen dann in den nächsten 8-Slot-Frame.  –  Aufgrund der Seriennummer lässt sich ein registrierter Sensor nicht noch einmal registrieren, so auch nicht die 8 Sensoren von JLog. Man muss sie erst aus dem Sender löschen. Wenn man zuvor gespielt/viel experimentiert hat, könnte es aber sein, dass vorangegangene Registrierungen anderer Sensoren benötigte Slots blockieren.  –  GPS-1675 (nicht mehr durch JLog verwendet) hat den höchsten Slot-Bedarf, nämlich 8 Slots, benötigt somit einen kompletten freien Frame. Dieser Sensor wird sich also am ehesten nicht mehr registrieren lassen, wenn Registrierungshistorie zu viele Slots besetzt hält, bzw. keine zusammenhängenden 8 freien Slots.

BEREITS BEIM BINDEN des Empfängers sollte alles richtig eingestellt sein im Sender, Mode (FASSTest 18CH bzw., eigentlich falsch bezeichnet, FASSTest-14CH in der T14SG), D/L (Delay, 0,5s), Telemetry ON(!), – sonst kann man u.U. zwar steuern, hat aber keine Telemetrie!
Es ist schon vorgekommen, dass beim Binden Mist passiert. In dem Fall war es dann so, dass der Sender nicht die Seriennummer des Rx gelernt hat, nach dem Binden überprüfbar in einem Menü des Senders.