Futaba und Telemetrie ?

[fun-flyer]

Hallo
Ob nun Futaba / Robbe Telemetrie bringt ist mir eigentlich genauso wurscht
wie das Angebot von graupner oder MPX ( zumindest was die Sensoren angeht )
So lange wie Firmen wie zb SM Modellbau keine Sensoren anbieten, die man auch
für Futaba nutzen kann , nutze ich eben für Modelle für ich Telemetrie haben möchte
ein anderes System .
Und das ist durchaus auch mit einem Futabasender möglich.

[garth]

Hi Funflyer,

klar, es ist mit jedem Sender möglich, den auf wasauchimmer umzurüsten. Nur hier ging es darum ob jemand heute noch eine neue Anlage kaufen sollte, die er dann erst noch umrüsten muß - Um danach ein selbstgebastelt umgerüstetes System zu haben, teuer als eine integrierte Lösung vom Wettbewerb. Meine Meinung : siehe oben.

[reinhpe]

Ich muss sowohl Tom als auch garth recht geben - nur was man nicht vergessen sollte: Es ist durchaus üblich, Neuentwicklungen 'Top Down' zu etablieren! D.h. es wird erst etwas neues im 'teuersten' Produkt vorgestellt und dann im Zuge der Modellpflege auf den 'billigeren' implementiert! Aus dieser Sicht macht es auch Sinn, d.h. es wird vermutlich die komplette Modellpalette über die Jahre neu aufgelegt werden - eben mit integrierter Telemetrie!

Nur robbe muss man schon den Vorwurf machen, dass sie mit ihrem Fiasko - Kästchen alles andere als einen guten Wurf gemacht haben! Der Versuch, nicht TM18 Besitzer mit Telemetrie zu versorgen ist ja gewaltig in die Hosen gegangen! Da hätten sie es lieber bleiben lassen sollen, so etwas ist nur peinlich. Was mich persönlich voll anstinkt: VOR der Vorstellung der Telemetriebox wurde von robbe immer der Anschein erweckt, als könnte man in den anderen Sendern 'vollumfänglich' Telemetrie nachrüsten - und das Versprechen haben sie sowas von garnicht erfüllt!

[fun-flyer]

Hallo

Hi Funflyer,

klar, es ist mit jedem Sender möglich, den auf wasauchimmer umzurüsten. Nur hier ging es darum ob jemand heute noch eine neue Anlage kaufen sollte, die er dann erst noch umrüsten muß - Um danach ein selbstgebastelt umgerüstetes System zu haben, teuer als eine integrierte Lösung vom Wettbewerb. Meine Meinung : siehe oben.

Es geht mir dabei weniger um den Sender sondern viel mehr um die Senoren-
Alles aus einer Hand schön und gut , bedeutet aber eine noch größere Herstellerbindung.
Nimm das Unilog zb. da ist es egal ob ich nun MPX / graupner oder **** fliege.
Oder die **** profibox samt Sat 2 Empfänger damit ist mit jeder Anlage Telemetrie möglich.
Senden mit Fasst / Telemetrie Empfangen mit **** Sensoren von SM.
Bei uns nutzen etliche schon lange das Unilog usw und für die meisten steht fest das
Telemetrie von Futaba erst Sinn macht wenn Sie von SM / WS usw unterstützt wird.

[fun-flyer]

Hallo

Ich muss sowohl Tom als auch garth recht geben - nur was man nicht vergessen sollte: Es ist durchaus üblich, Neuentwicklungen 'Top Down' zu etablieren! D.h. es wird erst etwas neues im 'teuersten' Produkt vorgestellt und dann im Zuge der Modellpflege auf den 'billigeren' implementiert!

vielleicht aus Sicht von Futaba das es andersrum Besser geht haben Graupner und MPX gezeigt.

[dl7uae]

Leute, beim Thema, ein Telemetriesystem zu nutzen, geht's aber nicht vornehmlich um die Sensoren, dabei auch nicht vorrangig um das Telemetrieprotokoll, ist zwar jedes Mal ärgerlich aufwändig, aber Reverse Engineering muss es dann eben heilen.

Es geht grundsätzlich immer und vornehmlich um das Telemetrie-Terminal! Was hat das Ding für "Löcher", um Daten darstellen zu können, und möglichst ohne "Vergewaltigung", also richtig nach Einheit und Wertebereich (dabei auch Kommastellung), spätestens eine Sprachausgabe lässt einen "Fake" hörbar werden. Da das Displaying eigentlich eher Schmuck am Nachthemd ist, mehr dem Spieltrieb verpflichtet, geht's vor allem auch um das Alarming, dabei gar nicht mal um die Ausgabeform (Piep, Sprache, Vibrator, E-Schock): Sind spezifische Alarme möglich oder nur ein Generalalarm? Wer löst den Alarm aus, der Sensor oder das Terminal? Einen Alarm am (genauer: im) Terminal definieren zu können (müssen), mag den meisten Anwedern als logisch, als richtiger Weg erscheinen, - aber, wenn das im Terminal nicht adäquat gemacht ist, hat ein Sensor gleich das nächste Mal Trauer um seinen Effekt im System. Kann er Alarme auslösen, ist er unabhängiger, braucht "nur" passende Alarmausgaben im Terminal.

So gesehen, hat Futaba es komplett falsch herum gemacht, extremst im Display (so "zugebaut" ist kein anderes System), aber auch bei der Alarmbildung.

"Zugebaut": Nun, das bezieht sich auf notwendiges "Akkreditieren" von Sensoren, für jeden Sensor, der die "Community" entern will, muss das Terminal aufgerüstet werden softwareseitig. Die T18MZ reduziert das aber auf das Übliche, ist dann sozusagen nicht mehr das Übel, nur das Übliche (siehe Fremdsensor an HiTec, Spektrum, - eigentlich auch HoTT, aber Graupner ist mit Nachentwicklungen auf Zack), - indem man als Sensor nun mehr oder weniger unpassende Datenklassen "vergewaltigen" kann, - und in der Beziehung bietet die T18 sogar ein Maß an Flexibilität, was an Systeme erinnert, die das extra implementiert haben, **** v1.1 (EX).

Die Notentwicklung von Robbe aber, die T-Box, bringt das "Zugebautsein" voll zur Geltung. Dazu kann man nur gratulieren.., und hoffen, dass sich an deren Weichware noch was tun wird.

Tom

[Sky]

Hallo Tom,

vielen Dank für deine fast unermüdlichen Bemühungen. Daumen hoch!

Ich kann mir vorstellen, dass es möglicherweise auch bald einen Stromsensor von Futaba geben könnte.
Da Futaba ja sehr eng mit OS Engine zusammenarbeitet und OS Engine schon seit längerem E-Motore und passende Regler im Programm hat.
So wie damals OS Engine mit Futaba den BPS-1 RPM Sensor entwickelt hat (speziell für OS Motoren),
kann ich mir vorstellen, dass da nun auch was in Richtung Stormsensor kommen könnte.

Lassen wir uns doch überraschen.

Wünsche dir noch einen schönen Tag.

[dl7uae]

Ich wollte noch ein P.S. anhängen, aber Timeout:

P.S. Rein IMHO: Schaut man sich den S.BUS2 an, elektrisch und vor allem das Protokoll, und betrachtet dann on top das Gesamtsystem, die klassenlosen Sensordaten auf dem Bus, das Terminal und der hausgemachte Irrsinn um das Zuweisen von 31 Time Slots, dann fällt Eines sofort auf:
Der Designer scheint nicht gerade besonders informiert gewesen zu sein im Modellbausektor der Telemetriebedürfnisse. Er hat das Ding offenbar vorrangig vom grünen Tisch aus entworfen. Und da sich ein Ingenieur auch in Nippon nicht lumpen lässt, hat er in Form des S.BUS2-Protokolls gleich mal Gigantomanie walten lassen. Leider blieben dabei praktische Gesichtspunkte unbetrachtet, sowohl innerhalb des Protokolls, aber vor allem der Anwendung von Telemetrie, "Sensoren" aus Sicht des S.BUS2, - die Destination der Daten der Sensoren blieb im Protokoll gleich mal unberücksichtigt, wurde dann als Nebenweg aufgepropft, und das ziemlich praxisfremd.
Wie gesagt, IMHO.

Man kann das sicherlich nicht mehr ändern, auch Robbe nicht, man kann aber versuchen, damit zu leben, - und das ginge. Wie gesagt, das Futaba-System ist hier nicht DAS Übel, es ist das Übliche, und hat aufgrund o.g. "Gigantomanie" sogar einige Vorteile. Das Problem ist das Terminal, und das lässt sich heilen, - reine Firmwarefrage im Sender. Anstatt nun bis in die Kiste schleppenderweise, wenn jeh..., [Fremd]Sensoren nachzuimplementieren, sollte man einfach die durch den S.BUS2 bestimmte Definitionslosigkeit von Sensordaten zu einer Tugend machen, indem man das Display im Setup entsprechend frei gestaltbar macht: Wertebereich, Kommastellung, Einheit, passende Sprachausgabe, passende Alarmlimits zum Einstellen. Gerade bzgl. Sprachausgabe passiert da bei Robbe/Futaba im Moment etwas, was so eine freie Gestaltbarkeit erst ermöglicht, da hat man dann die Nase vorn vor allen Systemen, die nur PCM-Dateien abspielen.
Der Gedanke, den User entlasten zu wollen durch so ein Akkreditieren in der Firmware bekannt zu seiender Sensoren (hinsichtlich von deren Dateninhalten), ist ja ganz nett, - aber lieber ein paar meckernde Anwender wg. dieses "immensen Aufwandes" eines einmaligen Setup des Terminals (Sender, T-Box) als ein never ending frustbasiertes Fiasko.

[augur]

Hast du schon gehört ob da denn ein "Datentyp" sonstiges wirklich geplant ist. Das wäre natürlich Luxus, dass man zu den definierten Sachen noch manuell was dazu definieren kann. Und die Windows CE software sollte ja Sprachsynthese hinbekommen.

Würdest du dir aus den Erfahrungen mit Robbe/Futaba ne T18 heute holen und auch von den technischen Möglichkeiten, dass vorhandene (S.BUS2,...) gut auszubauen? Will eigentlich gerade umsteigen von der T12, bin mir aber wegen dem undefinierten Zustand unschlüssig.

[dl7uae]

Nils, die Frage ging an mich? Nein, ich habe eigentlich keinerlei Informationen. Dass ich die Möglichkeit zu manueller Slot-Zuweisung in der T18 "damals" nutzte, war einfach eine Notlösung, damit überhaupt was geht. Es hieß dann seitens Robbe, dass man den Sensor "JLog", seine Telemetriedatenstruktur, dann irgendwann in die Firmware bringen würde, also der T18, und, so nahm ich zumindest an, anderer relevanter Terminals.

Es bleibt nun mal das Prinzip des Systems, dass Sensoren am Terminal registriert werden, und das Terminal macht die Slot-Zuweisung automatisch. Bzgl. JLog ist hier wesentlicher, dass es dann zu dessen Daten passende Displays gibt, was jetzt kaum der Fall ist.

So ein Sensor wie das Vario Picolario2 Duo hat es da einfacher, er muss nur die Registrierung unterstützen, mit der richtigen ID, und schon ist alles in Butter, denn seine Daten entsprechen denen anderer Varios, der/dem von Futaba.

Ich könnte jetzt natürlich JLog auf die gleiche Weise sich als x Temperatur- und Drehzahlsensoren registrieren lassen, das würde aber am Istzustand nur ändern, dass dieses "Vergewaltigen" fremder Displays dann auch mit der Telemetriebox ginge, man nicht mehr davon abhängig ist, dass das Terminal manuelle Slot-Zuweisung kann. Das wäre nicht schick, aber machbar, - und mit anderen Telemetrien muss ich es ja auch machen, HiTec, Spektrum, teilweise HoTT im Moment noch. Ich weiß aber im Augenblick nicht, wie praktisch in der Handhabung es wäre, einen physischen Sensor in n Registrierungen sich mal als den mal als jenen Sensor darstellen zu lassen, 12..16 mal.

Tom

[augur]

Nils, die Frage ging an mich? Nein, ich habe eigentlich keinerlei Informationen. Dass ich die Möglichkeit zu manueller Slot-Zuweisung in der T18 "damals" nutzte, war einfach eine Notlösung, damit überhaupt was geht. Es hieß dann seitens Robbe, dass man den Sensor "JLog", seine Telemetriedatenstruktur, dann irgendwann in die Firmware bringen würde, also der T18, und, so nahm ich zumindest an, anderer relevanter Terminals.

Ich finde es eigentlich voll ok das manuell zu machen. Die automatische Registrierung ist halt die Kirsche auf der Sahne. Aber frei definierbare Displays wären nett. Die Registrierung macht man ja auch nicht vor jedem Flug. Das Telemetrie Display ist halt "unfähig" designed worden.

Noch zur zweiten Frage (auch wenn bei mir nun schon zu spät), würdest du mit deiner Erfahrung über Protokoll SBus 2 und Funktion der T18 diese kaufen und auf den Ausbau der Funktionen in Zukunft setzen. So eigentlich müsste da ja alles möglich sein, oder nicht?

Viele Grüße,
Nils

[dl7uae]

Das ist jetzt 'ne Frage... Die habe ich eigentlich schon mehrfach indirekt beantwortet.
Und außerdem habe ich natürlich auch prinzipiell eine eigene Sichtweise. Ich sagte ja schon mal, ich würde es wie keines der bekannten Systeme machen, wenn ich die Wahl des Designs hätte.

Aber, klare Frage, klare Antwort:
Wenn die Kohle für mich keine Rolle spielte, würde ich mir wahrscheinlich heute eine T18MZ kaufen, yep. Das große, farbige Display, Bedienung per Touchscreen, die glasklare Sprachausgabe, die funktionale Mächtigkeit im Hauptbereich der Applikation, das edle Design, ... wären meine Gründe.

Der S.BUS2 und die Art und Weise der Implementierung der Telemetrieterminals sind kein Hinderungsgrund, dass sich Futaba nicht auch im Telemetriebereich als Spitzenprodukt etablieren könnte. Ich bin sogar überzeugt davon, dass es so kommen wird. Nur im Augenblick ist das für den Anwender noch nicht voll rund, es gibt noch einiges zu tun, vornehmlich an der Palette im Senderbereich. Tja, und am Ende werden etliche Leute doch was anderes kaufen, des Geldes wegen.

Alle 6 Systeme, die JLog im Augenblick unterstützt, können bereits heute die wesentlichen Anwenderwünsche erfüllen, werden es zumindest morgen können, 100 Pro.

Das einzige Alleinstellungsmerkmal des S.BUS2 ist, dass er als Universalbus dienen kann, also auch zu den Servos, von Gyros direkt zu Servos etc. Ob sich das durchsetzt (bei Futaba-Anwendern), wird man sehen, vor allem, ob S.BUS2 gegenüber klassischen Servoimpulsen auf Einzelkanälen auch in der Masse der verschiedenen Modelle überhaupt seine Vorteile ausspielen können wird. Die Leute kaufen sich ja nicht immer alle Servos neu. Hier kann man sich ja schon an S.BUS (1) einen Eindruck verschaffen.

Summasummarum: Das System behindert sich auf keinen Fall selbst, ergo gibt es keinen Grund, pessimistisch zu sein.
Der Zeitfaktor bzgl. Weiterentwicklung und Verfügbarkeit wird natürlich auch ein Argument sein, - heute, aber die Anschaffenden morgen juckt das nicht mehr, es ist dann einfach da.

Um's mal ganz klar zu sagen: Ohne die Akzente, die **** und HoTT setzten, Multiplex on top, würde man das nicht so verschärft sehen. Und das wird auch der Grund sein, weshalb im Einzugsbereich der drei die Negativ-Publicity für Futaba so krass ausfällt.

[augur]

Summasummarum: Das System behindert sich auf keinen Fall selbst, ergo gibt es keinen Grund, pessimistisch zu sein.
Der Zeitfaktor bzgl. Weiterentwicklung und Verfügbarkeit wird natürlich auch ein Argument sein, - heute, aber die Anschaffenden morgen juckt das nicht mehr, es ist dann einfach da.

Das ist eine sehr gute Info, dann habe ich ja nichts falsch gemacht. Mir kam das schon so vor, als wären die Möglichkeiten durch die Umsetzung schon stark begrenzt.

Gruß,
Nils

[fun-flyer]

Hallo

Das einzige Alleinstellungsmerkmal des S.BUS2 ist, dass er als Universalbus dienen kann, also auch zu den Servos, von Gyros direkt zu Servos etc.

hier liegt aber die Betonung auf kann, denn laut der bisherigen Beschreibung zu den Empfängern
soll der S Bus 2 ausschlieslich für Sensoren benutzt werden

Und die Windows CE software sollte ja Sprachsynthese hinbekommen.

Du sollest aber bedenken das die T 18 ein Sender für die Minderheit ist und nicht unter Win CE laufen.

futaba sollte endlich mal das ganze System überarbeiten und eine einhaltliche Line schaffen
Sehen wir uns das doch mal an CH 7 Modus / Multi Modus / Multi 2 Modus / S bus und S Bus 2
mal sehn was sonst noch dazu kommt

[Elektro]

Hallo fun-flyer,

ich bin einer von der "Minderheit".

Hallo
hier liegt aber die Betonung auf kann, denn laut der bisherigen Beschreibung zu den Empfängern
soll der S Bus 2 ausschlieslich für Sensoren benutzt werden

Du sollest aber bedenken das die T 18 ein Sender für die Minderheit ist und nicht unter Win CE laufen.

Damit liegst Du leider falsch.

1. Die die T18 im FASSTest-Mode bedient nur noch den S-Bus2 am Empfänger ( bidirektional für Alles ).
2. Windows CE ist ja nur eine " komfortable Visualisierung " der eigentlichen Fernsteuer-Software, die sich auf einem anderen Chip wie WinCE läuft.
Windows CE eignet sich nicht als Echtzeitsystem, mit dem man etwas " gefährliches " steuern könnte .


Viele Grüsse
Uwe