T18 Software im Breeich der Telemetrie

[Sky]

Schauma mal, was die Zukunft so bringt.

Habe bereits einen Futaba Temp. Sensor der bis +200' geht.


Gesendet von meinem iPad 4G 32GB mit Tapatalk HD

[dl7uae]

Ähmm.., ich hab' mir das eben noch mal durchgelesen, hier gibt es möglicherweise ein Verständnisproblem, was zu Mißverständnissen führt:

Der S.BUS2 ist eine eierlegende Wollmilchsau für: Servodaten von bis zu zwei Rx an Servos, Gyros an Servos, Setupdaten an Busdevices, Sensoren an Rx (und damit retour zum Terminal, - Sender (i.Augenblick nur T18), T-Box oder WiFi-Rx).
Das Protokoll ist relativ komplex. Es besteht aus 4 Frames mit je 8 von 32 Slots für Sensordaten, Servodaten werden vollständig in jedem Frame übertragen. Die Latenz ist gering, die Übertragungsrate entsprechend hinreichend hoch (100kbps).

Das Businterface für jeden Teilnehmer ist parametrisch vorgeschrieben, sodass Fehlfunktion eines Devices zumindest theoretisch nicht zum Blockieren des Busses führen kann, denn das könnte tödlich für's Modell sein. In meinen praktischen Tests konnte ich auch mit einem Worst-Case-Szenario, Datenleitung eines Devices hinter der vorgeschriebenen Kopplungsschaltung statisch auf Masse oder +3,3V, kein Blockieren verursachen.
Für Fremddevices kann es u.U. etwas hinderlich sein, dass das Bussignal invertiert wird (externer Koppler erforderlich). Hat das Fremdgerät eine weitere Signalleitung frei, wird es einfacher, - ohne Koppler kommt es aus, wenn es das asynchron-serielle Protokoll komplett in Software macht (SM macht das bisher), also keinen UART seines Microcontrollers verwendet. Am besten sind Fremdgeräte dran, die direkt auch für den S.BUS2-Anschluss designed wurden, - mit einem JLog3 würde das der Fall sein.

Zurück zu den Sensoren: 32 Time Slots, der erste davon wird fix vom Empfänger beansprucht für Signalqualität/Rx-Spannung/optionale ext. Spannung. Slot 0 wird vom Rx besetzt, um diese Daten später auch mit einem Flightrecorder aufzeichnen zu können, der lutscht ja alles vom Bus. Es verbleiben also 31 Time Slots für weitere Sensordaten. (Der Empfänger als Sensor benutzt nur FASSTest®, weil er ja derjenige ist, der das mit dem Terminal quasselt, - auf den S.BUS2 sendet er nur für einen späteren Recorder.)
Multi-Sensoren (liefern mehr als einen Wert, siehe z.B. Robbe/Futaba GPS und Vario, aber auch JLog und Unilog) werden mehrere Time Slots beanspruchen. Diese Slots müssen fortlaufend besetzt werden, außerdem müssen sie jeweils in einen Frame von maximal 8 Slots passen, können sich aber über mehrere Frames erstrecken.
Um das Slot Management für den Anwender transparent zu machen (von ihm fernzuhalten), kennt die Firmware des Terminals jeden Sensor anhand einer von Robbe/Futaba vergebenen ID, die dieser führt, es muss also sozusagen mal einen Zertifizierungsprozess gegeben haben, für Sensoren von Robbe/Futaba logischerweise selbstverständlich, ergo nur für Fremdsensoren interessant. Wie das mit den Terminals "T-Box" und "WiFi-Rx" gemacht ist, weiß ich nicht, bei der T18MZ wird dazu der Sensor einmalig direkt an den Sender angeschlossen, und mittels eines Extra-Protokolls nimmt die T18 den Sensor wahr (anhand seiner dem Terminal bekannten ID) und teilt ihm seine Time Slots mit. Die T18 macht also ein automatisches Management der Time Slots, jedes Mal, wenn ein weiterer Sensor zur Akkreditierung angeschlossen wird.
Alternativ kann die Slot-Verwaltung, Slot-Nummer und Sensortyp (bei Multi-Sensoren dadurch automatisch auch die Datentypen je belegtem Slot) manuell gemacht werden.

Und da sind wir bei der Formulierung von mir, dass JLog2 als Sensor erst in die Firmware der T18MZ als Terminal (in T-Box und WiFi-Rx ebenso) einzubauen ist:
Das Terminal muss spezifische Datentypen, die ein Slot eines Sensors benötigt, kennen, Wertebereich und Maßeinheit, das betrifft dann auch die Sprachausgabe. Außerdem wird dem Terminal ein Sensor als Slot-Block beigebracht, wieviele (zusammenhängende) Slots benötigt werden und von welchem Datentyp in welcher Reihenfolge jeder Slot ist. Zusätzlich lernt das Terminal das Notwendige, um die o.g. Akkreditierung machen zu können. Das Akkreditieren ist praktisch, muss aber nicht sein, es ginge auch ohne.

Im Augenblick kennt das Terminal "T18MZ" 4 Sensortypen entsprechend dem momentanen Sensorportfolio von Robbe/Futaba, 2 Einzel-Slot-Sensoren, Temperatur (°C) und Drehzahl (rpm), 2 Multi-Slot-Sensoren, Vario (3 Slots) und GPS (8 Slots). (Praktisch ist hier, dass man einem Drehzahlsensorfeld eine Untersetzung mitgeben kann im Terminal.)
Ein Fremdsensor, dem Terminal unbekannt (hat keine ID, kann nicht beim Direktanschluss an das Terminal "akkreditiert" werden), kann sich hier durchaus bedienen, sofern er sich nur an das Protokoll des S.BUS2 und die Anschlussparameter hält, und das Setup der Sensoren in ihren Slots am Terminal adäquat zur Slotbelegung durch den Sensor erfolgte. Trauer hat er nur, wenn ein Datentyp, den er in einen Slot packt, dem Terminal momentan unbekannt ist, also z.B. "PWM" in "%", "Kapazität" in "mAh", "Strom" in "A". Die Trauer betrifft die Maßeinheit zum Wert, vor allem auch in der Sprachausgabe, - u.U. auch den Wertebereich.

Glücklicherweise kann man die Slots (Datenfelder) zumindest im Terminal "T18MZ" relativ frei beschriften. Die Möglichkeiten, im Terminal Alarme zu setzen auf Überschreiten oder Unterschreiten eines numerischen Wertes, sind i.Allg. völlig ausreichend, solange man einen dem Terminal bekannten Datentyp wählte, der einen passenden Wertebereich anbietet. Das ist die Schiene, auf der JLog2 im Augenblick mit der T18 quasselt, also weder Hexenwerk noch unendliches Verbiegen.

------
Nun kann man sich im Vergleich der verschiedenen Telemetriesysteme am Markt trefflich streiten, was nun besser gewesen wäre. Zu obigem "Problem" kann man feststellen, dass einzig **** EX, also dessen "Hidden Protocol v1.1", Möglichkeiten bietet, dass ein Sensor selbst Wertebereich, Datentyp (Maßeinheit) und Beschriftung eines Datenfeldes bestimmen kann. (Das Arbeiten im rein alphanumerischen Punkt-zu-Punkt-Terminalbetrieb entsprechend **** Basisprotokoll oder auch der adressierte HoTT Textmode können hierzu nicht verglichen werden, weil Äpfel und Birnen.) Würde man mich danach fragen, wäre meine Antwort: Mein Design sähe anders aus als alles bekannte, hätte aber Ähnlichkeiten mit solchem, ein bisschen MSB, ein bisschen HoTT, ein bisschen **** EX, ein bisschen Futaba.

Nun ist mal der Berg zum Propheten gekommen, kann eigentlich im entsprechenden Artikel auf meiner Info-Seite j-log.net nachgelesen werden. K.A., was mich ritt, bin vielleicht nach der Woche Urlaub zu erholt. Na ja, dem wird dann ab morgen wieder kräftig abgeholfen. Will sagen, solche Pamphlete in Foren habe ich mir eigentlich längst abgewöhnt, und dabei soll es bleiben. Dachte nur, dass ein paar direkte Worte im Futaba-Forum vielleicht ganz gut aufgehoben wären, - und siehe da, ich hatte sogar einen Account hier.

Tom

[rudi1025]

Hi Tom,

Hab ja auch Jlog2 mit Linus Board.
Funktioniert mit den genannten Einschränkungen einwandfrei.

Wie jeder weiß, gibts derzeit noch nichts von robbe/futaba und darum ist es einfach super das es funktioniert und beweißt das es keine Unmöglichkeit ist sich ans S-Bus2-Protokoll zu hängen.
Natürlich ist das hier nur die einfachste Version der Anwendung des S-Bus2 aber der Anfang ist gemacht.

Darum von mit Gratulation an Tom und Linus.

LG
RUDI

[hessc]

Traurig, traurig...

Hallo Dr. Tom,

tolle Leistung von dir!
Aber ich hätte dann doch lieber echte Futaba Telemetrie.
Und wenn schon Sprachausgabe, dann Futaba Sprachausgabe wie jetzt.
Bei einem Spitzensender, will ich keine 08/15 Ansage.
Willst du es hier veröffentlichen, was deiner Meinung die Ing., Doktoren und Informatiker von Futaba nicht schaffen und lt. deiner Meinung geändert gehört und wie es diese studierten besser machen könnten?

Geht eigentlich die Garantie verloren bei deinen Maßnahmen?
Oder wenn ein Modell einen Sachschaden verursacht, weil durch diese "Veränderung" einen Ausfall der Sendeanlage verursachte?
Wie schaut es da mit der Modellflugversicherung aus?
Wann wäre deine Veränderung Marktreif?

Gesendet von meinem iPad 4G 32GB mit Tapatalk HD

Meine Güte, Leute gibt's... *kopfschüttel*

eigentlich wollte ich gar nix schreiben, aber es ist einfach unfassbar, wie die Arbeit von hochqualifizierten und engagierten Leuten wie Tom und Linus hier von arroganten .... mit Dreck beworfen wird...! Sky, vielleicht solltest Du Dich mal zuerst mit der Materie und den beteiligten Personen auseinander setzen (zumindest versuchen...), bevor Du hier unqualifizierte Sprüche abgibst! Unterste Schublade...

Hallo Gottfried.
Was sollen eigentlich schon wieder diese unterschwelligen Andeutungen? Wenn Du fundierte Informationen hast, dann raus damit, aber die Arbeit anderer Menschen mit unbegründeten Behauptungen schlecht zu machen geht gar nicht. Entweder Du hältst Dich an die Regeln, oder machst Dein eigenes Forum in dem Du andere mit Dreck bewerfen kannst wie es Dir passt.

Bitte seid doch so konsequent... wäre schade um dieses Forum...

LG
Christopher

[Sky]

von hochqualifizierten und engagierten Leuten wie Tom und Linus hier von arroganten .... mit Dreck beworfen wird...!

Zeigst Du mir bitte eine Stelle wo mit "Dreck" geworfen wurde?
Ich sehe nur Fragestellungen und keine Behauptungen.

Danke!


Gesendet von meinem iPad 4G 32GB mit Tapatalk HD

[Sunny]

Ich sehe nur Fragestellungen und keine Behauptungen.

Es sind aber Suggestivfragen - gegen die Nettiquette!

[dl7uae]

Na gut.., es gibt eben verschiedene Ansätze, und alles hat seine Pros und Cons, seine Limits.

Mit dem Ansatz eines "dummen Terminals", **** Basis bzw. der optionale Text Mode in HoTT, könnte jeder Sensor sofort uneingeschränkt vom Leder ziehen, - doch die Alarme, zu erzeugen im Sensor, müssen auch ihre Entsprechung finden können. Werteansagen bedürften einer textuellen Interpretation, wozu man den möglichen Output jedes Sensor stellengenau kennen muss, was prinzipbedingte Flexibilität der Anzeige wieder zunichte macht. Volker macht dieses Interpretieren mit seinem Vspeak.

Auch mit dem MSB von Multiplex könnte man sofort loslegen, nur ist man auf die vorgegebenen Datentypen und ihre Wertebereiche beschränkt, auch hier wären teilweise Datentypen oder Wertebereiche zu vergewaltigen (was JLog auch seit der Steinzeit macht).

**** EX erlaubt Sensoren, sich auf relativ wenigen Displays in hoher (aber auch limitierter) Freiheit selbst definierend auszutoben, Alarme bildet der Sensor.

Der Binärmode von HoTT bindet alles in starre Komplexdisplays, JLog hat deshalb gerade hier keinen vollständig passenden Schuh finden können, und, wie's aussieht, wird selbst ein zukünftiger HoTT-Nachfolgesensor von Graupner mit solchen Kompromissen leben müssen. Alarme bildet auch hier der Sensor, HoTT bietet nur den Alarmgeber, ebenso wie in **** und MSB/M-Link.

HiTec zieht nicht nur die Dateninterpretation in das Terminal (den Sender), sogar das Data Processing, die HiTec Sensor Station (HTS) ist nur ein dummer Collector, Sensor-Interface. Was der Sender nicht kennt, ist im Prinzip nicht darstellbar, schlimmer noch, man muss teilweise Daten "vorverzerrt" anbieten, damit das dargestellt wird, was man ausgeben will. Dadurch wird die Alarmbildung im Sender besonders behindert mit Fremdsensoren, die Daten anbieten, deren Typ das System nicht kennt. HiTec klingelt via I²C (synchron-seriell, 400kbps), während die anderen hier genannten Systeme alle asynchron-seriell brabbeln, von 9600Bd (****) bis 100kBd (S.BUS2).

Bei Futaba sind Datentypen, deren Interpretation und Alarme darauf, rein Sache des Terminals, dafür ist der Datenpfad dorthin, der Bus am Empfänger, bzgl. zu übertragener Inhalte nicht eingeschränkt. Diese Sensorslots haben sozusagen kein Geschlecht. Die Firmware des Terminals, wie der T18, wird nun sukzessive Datentypen lernen müssen, gleichzeitig identifizierte Sensoren, die solche Datentypen in einem spezifischen Slot-Gefüge verwenden.

Was die Alarme betrifft, kann man sich mal wieder gut streiten, was besser ist, Alarmbildung im Sensor oder im Terminal.. Alarmbildung im Terminal, wenn so flexibel gemacht wie in der T18, hat sicherlich Vorteile. Andererseits kann es aber auch von Vorteil sein, wenn der Sensor die Alarme bildet, das Terminal nur der Alarmgeber ist. Das ist immer dann der Fall, wenn es gut wäre, einen Alarm der State Machine des Sensors zu unterstellen. Beispiel: JLog macht einen Warmstart, wenn der Antriebsakku am JIVE gewechselt wird, der BEC (und damit der Logger) aber gepuffert ist.

Und zurück zu Futaba: Der Anpassungbedarf im Terminal ist beim gewählten Prinzip völlig normal und auch nicht ungewöhnlich, siehe die Vergleiche mit anderen Telemetriesystemen oben. Es ist ja wohl logisch, dass die Terminals zunächst nur Datentypen kennen, die im Startportfolio systemeigener Sensoren vorkommen. Wie ich glaube, gibt es auch noch Modifikationsbedarf im Bereich des Alarm Handling (Display, Tone und Speech), das ist einfach eine Sache des Erfahrungsammelns in der Praxis, die gerade erst beginnt.

-----
Tja.., eigentlich völlig OT: Es hat sich einiger Frust aufgestaut, da kann ich aus menschlichen Gesichtspunkten gut verstehen, dass Dinge, selbst, wenn sie sich endlich wirksam entwickeln, durch einen besonders kritischen Filter betrachtet werden. Hey, mal richtig auf'n Tisch hauen, kann ich manchmal auch ganz gut, der Dampf muss eben raus. Wenn wir aber in der Öffentlichkeit über solche profanen, rein technischen Angelegenheiten reden, dann sollten wir verzerrende Emotionen draußen lassen, sie passen nicht zur exakten Sprache der Technik.

Tom