Ähmm..., fromme Wünsche.
Systematisieren wir es doch einmal:
Ganz unten stehen irgendwelche Gerätschaften oder Umgebungsbedingungen, von denen man irgendwelche Meßwerte abnehmen will.
Ganz oben steht ein Ding mit Display, Sprachausgabe, Piep-Piep, Vibrator, Elektroschock (ach nee, bisher noch nich
), was den Benutzer informieren soll.
Was braucht man dafür? Sensoren, - im ursprünglichen Sinne des Wortes, nicht in dem verballhornten der HoTT-Nomenklatur.
Das sind Temperatursensoren, passive nichtlineare (NTC, PTC), aktive lineare (analog, digital), RPM-Impulsgeber, Speed Sensoren, Drucksensoren, ... Schokoweihnachtsmann. All diese Dinger haben irgendeine elektrische Schnittstelle, Wertebereiche und -funktionen bzw. Kommunikationsprotokolle, die es zu bedienen gilt.
On top kommen Devices, deren (proprietärer!) Output nach Datenverarbeitung virtuelle Sensoren bereitstellt. Da gibt es so einen Typ, der fing mit dem Kram an, anhand eines JIVE, nun macht er es auch mit ESCs von Castle Creations, und, wer weiß..
, vielleicht auch demnächst mit anderen.
Damit sind wir beim zweiten Step, einem Dingelchen, was all diese benötigten Schnittstellen hat, und die Funktion in Software, um daraus die gewünschten Daten extrahieren zu können. Will sagen, dieser Kasten ist zwangsläufig proprietär, in dem Sinne, dass er nur eine spezifizierte Bunch von Sensoren unterstützt, und nur die. Das ist leider unvermeidbar.
(Allerdings geht der Trend dahin, dass zumindest komplexe (Multi-)Sensoren, ESCs, Drucksensor mit Höhenformel und Variofunktion, GPS-Rx usw. selbst direkt schon ein Telemetrieprotokoll sprechen, zum Empfänger hin, der den T-Bus aufspannt. Natürlich ist damit die (proprietäre) Systemzugehörigkeit gleich zementiert. -- Aber andererseits könnte das einem "als Intersystem-Kleister" fungierenden Gerät es sogar einfacher machen, es muss nur noch als Telemetrie-Gateway unterwegs sein, - JLog3 wird so was auch können.)
So.. Was brauchen wir dann?
Klar, wir brauchen ein adäquates Terminal, s.o. Aber erst mal müssen die Daten dort hinkommen, wireless.
Aha..., auf welcher Frequenz funken wir, koordiniert (wenn im selben Band wie FS) oder unkoordiniert?
Welches Modulationsverfahren, und, last but not least, welches Kommunikationsprotokoll auf der obersten Schicht quatschen wir denn?
Klar doch, natürlich eines, was das Terminal und sein Empfänger versteht.
Nun sind wir beim Terminal, mein Auslöser für den Thread hier...
Solange ich das selbst stricken kann, habe ich alles in der Hand, kann meine gewonnen Daten passend loswerden. Dann muss ich aber auch Herr über die Schnittstelle zur Übertragungsstrecke sein können, sprich, ich funke gleich selbst. Doch wenn das Terminal ein Fremdprodukt ist, standalone (IISI, Robbe T-Box, JBP) oder embedded in einen Sender, selbst Bestandteil eines in sich geschlossenen Systems, mit mehr oder weniger Möglichkeiten der Datengewinnung, mehr oder weniger durchdacht, und vor allem weniger bis gar nicht auf Offenheit konzipiert, - dann geht die Trauer los.
Will sagen: Natürlich wäre es easy möglich, zumindest ein Protokoll und Terminalfunktionen darauf zu definieren, die allen Datenquellen und deren Bedürfnissen des An-den-Mann-Bringens gerecht werden könnten. Nur wird sich das nicht allgemein durchsetzen, es wäre nur ein weiteres System, was sich vielleicht funktionell abhebt. Dann muss es nur noch zum Schenkungspreis verfügbar sein, mit teurem Marketingsrummel sich in díe Umsatzsegel blasend (geht ohne Asien-Fertigung eh nicht), und gegen die Argumente der ganzen Schlaumeier, genannt Konsumenten, bestehen können. Ich meine solche wie "Bei HK ist alles ganz billig und das (katastrophale) Quanum ist super!" oder "Mir kommt kein Vogelhäuschen an meinen doofen Sender".
Du siehst, Jupp, wie man es auch dreht und wendet, am Ende ist jede Lösung eine proprietäre, - und nur ein paar Unentwegte werden in einem Hase-Igel-Spiel weiterhin versuchen, durch irgendwelche Vielfalt zu glänzen, siehe SM und meine Wenigkeit. Aber diese Dinger sind eben auch nicht "universell", sie sind nur der Kit zwischen lauter inkompatiblen Spielzeugen, - und die Spielzeughersteller tun i.Allg. einen Dreck dafür, wenigstens auf der Terminalseite entgegen zu kommen. Im Gegenteil, sie lassen dich in ihren Kram häufig am liebsten nicht reingucken, - Reverse Engineering geht meist schneller, als ein Stück Papier unter NDA zu bekommen.
Bisschen spät (früh) schon... Konnte ich rüber bringen, warum ich es "fromme Wünsche" titulierte?
P.S. Mal beobachtet? Dieser ganze Telemetrie-Hype scheint im Moment eine Deutsche, höchstens vielleicht eine Westeuropäische Erscheinung zu sein, während der Rest des Globus bisher keinen gesteigerten Wert auf solche Spielzeuge legt. Und wenn dann dort was in's Rollen kommen sollte, dann werden die Lokalmatadoren der FS-Systemhersteller den Ton angeben, in US z.B. Horizon/Spektrum und die Klingonen-Dinger von JR, bisschen Futaba on top. Bingo. Die (gebremsten) Möglichkeiten werden die Bedürfnisse regulieren. - Graupner versucht sein Möglichstes, aber mMn kein Grund, zu befürchten, dass Horizon deswg. demnächst am Stock gehen wird. Und Futaba kann ganz entspannt bleiben mMn, in dem Sinne haben die noch lange nicht die Welt verpennt, ganz im Gegenteil, sie sind früher wach, als dass der Wecker in den umsatzträchtigen Regionen gerappelt hat. Nur Robbe hat speziell in Deutschland ein bisschen die A-Karte davon. Doch auch hier: Man vergleiche doch mal, was Futaba bisher an Sensorik kann, eben erst nach langem Hin und Her auf der Matte erschienen, und was andere, weniger bescholtene, nach verhältnismäßig langer Zeit immer noch nicht können. Das eigentliche Ärgernis kann im Vergleich zu Spektrum, z.B., doch gar nicht sein, dass es bisher nur einen Sender gibt, der als Terminal fungieren kann. Das Ärgernis ist doch nur, dass dieser Sender so teuer ist. Und on top nun noch, nach heroischer Eigeninitiative aus der Not heraus, die z.Z. etwas schaumgebremste Funktionalität der "Ersatzbefriedigung" T-Box von Robbe.
Anmelden
Registrieren
FAQ
Suche
