Telemetrie vs. Alarming

[dl7uae]

Hi!

Der Titel ist etwas unklar. Konkret geht es um folgende Frage, bzgl. derer ich gerne mal kurz eine Diskussion vom Zaun brechen möchte:

Jemand aus helifreak.com beballert mich mit seinen Wünschen. Der Aufhänger ist natürlich JLog, was denn sonst.

Da mir seine spieltriebhaften Vorstellungen nicht ungeeignet erscheinen, so auf eine gewisse Masse zu verallgemeinern, würde ich das gerne hier mal bequatschen:

Es geht um Alarme, die er bis in seinen Sender haben will.

Dabei geht's ja um zwei Fragen:

- Wo enstehen die Alarme? Sprich, an welcher Stelle werden Schwellenwerte ausgewertet und ein Alarm ausgelöst?

- Wie kommt der Alarm zum Piloten? Abgesehen von Blitzen, Hupen, Tuten, Motorstottern und Rauchzeichen ist ja im Augenblick in aller Munde, das wireless zu machen. Spieltrieb eben, der zunehmend durch Hersteller befördert wird, sei es Jeti, Spektrum, sonstwer.

Unterthema Wireless:

- Man kann "irgendwas" nehmen, also R/C-fremde ISM-Technik.

- Das Jeti Telemetrieprotokoll, modifiziertes 1-Wire, ist ja quasi offen, auch, wenn Jeti selbst es nicht breit tritt. Positiv hinzu kommt, dass die Jetibox am Ende der Telemetriekette quasi für jedweden Zweck der Signalisierung und Darstellung in zwei 16-stelligen Zeilen dabei verwendet werden kann.

- Spektrum: Es gibt keine beschriebene Schnittstelle auf der Modellseite, vermutlich auch keine offene. Ob "internal telemetry DATA" dafür verwendet werden könnte, weiß ich im Moment nicht, ob der "X-Bus" eine Alternative sein könnte, wie er verwendet werden kann, und ob der überhaupt schon in der Software des TM1000 implementiert ist, weiß ich auch nicht. ----------- Jedenfalls, kommt man an's andere Ende der Telemetrie, in den Sender, eine DX8, z.B., landet man eh bei einem proprietären Display. Das ist ja wohl auf bestimmte Messwerte festgenagelt und nicht so offen verwendbar wie die Jetibox.

* Und damit sind wir bei der anderen Idee, die generell auf jede Telemetrie anwendbar wäre: Ich emuliere Sensoren, gebe in die Schnittstellen (eines TM1000, z.B.) eine Impulsfrequenz rein, wo ein RPM-Sensor ran soll, ansonsten statt der anderen Sensoren kommt da eine Spannung rein. Also Frequenz oder Spannung als Ersatzgröße für irgendeinen Messwert, den ich übertragen lassen will. ...Und anzeigen: Und da sind wir wieder bei der proprietären Komponente des Displaying im Sender..

------
Nun wertet JLog ja selbst relevante Schwellwerte aus, generiert Alarme, die im Augenblick in einen Generalalarm enden. Ich will/muss eigentlich nur ein Alarmsignal übertragen, Schwellwerte und Größen (einschließlich deren Anzeige) interessieren mich nur als Ein/Aus.

Nun frage ich mich ganz generell, welchen Sinn das Ganze oben machen soll, Messwerte zu übertragen, um sie im Telemetrie empfangenden Sender auszuwerten, einen Alarm zu generieren, wenn man das im Modell bereits hat?

Meine Frage ist ganz genereller Natur?

Kann ich denn während des Fluges auf's Display schielen, will ich das, sollte ich das?

Ist es nicht vielmehr so, dass ich nur Alarme will, akustisch (aus dem Sendergehäuse) oder mittels Vibrator?

Ist es wirklich erwünscht, unterschiedliche Alarme zu empfangen, also akustisch oder als Vib-Sequenz unterscheidbar? Könnte ich das in der Anspannung des Fluges überhaupt unterscheiden?

Echte Messwerte sind also im Flug eher uninteressant, sie sind Objekte der Forensik. Aha, Forensik... Die meisten Telemetriesysteme zeichnen aber nicht auf, es ist ein reines Just-in-time-Display.

Zurück zu JLog: Der zeichnet auf (logged), sowohl die verursachenden Werte als auch die Alarme als Auswirkung, je nach Setup der Schwellwerte. Ergo sollte/muss ich das nutzen für Forensik, ergo muss/sollte ich nur die Alarme übertragen. Und dabei eben die Frage, ob Differenzierung überhaupt sinnvoll ist, also ein Generalalarm nicht ausreicht? ----- Abgesehen davon, dass möglicherweise die z.V. stehen ßbertragungsstrecken (Telemetriesysteme) auf der Ausgangsseite eh keine unterscheidbaren Alarme signalisieren können(?)

Zusammengefasst: Gesetzt den Fall, ich habe einen konfigurierbaren (Schwellwerte) und aufzeichnenden (Logging) Alarmgeber wie JLog: Sollte ich dann nicht nur den Alarm übertragen? Wenn ja, nur einen (Generalalarm) oder doch verschiedene?

Bei der Idee des o.g. Kollegen, Sensoren am TM1000 zu emulieren, geht mir nämlich nach obiger ßberlegung jeder Drive ab, das umzusetzen. Es ist so wie ein Klappfahrrad zu erfinden, obwohl man bereits ein Rennrad hat. Außerdem erntet man am Ende eine beknackte Art und Weise der Anzeige (DX8), bei der die Werte falsch betitelt werden und die Maßeinheiten Bullshit sind, weil man ja die Strecke für andere Messwerte mißbraucht. Tja, und dabei ist das auch noch ziemlich sinnlos, weil die Anzeige der Messwerte während des Fluges eh nicht genutzt werden kann, die variablen Werte eh nur zum Bedienen von Alarmschwellen im Sender benutzt werden. ------ Nur.., warum soll ich Messwerte zur Schwellwertbegutachtung erst übertragen, wenn ich das am Ort derer Entstehung bereits tat?!!

...........

[speedy610]

AW: Telemetrie vs. Alarming

Hallo Tom,

ich kann hier nur mal etwas zum Ablesen irgendwelcher Daten während dem Flug sagen. Ich fliege seit längerem das iiSi Telemetrie System und habe nur die Kapazitätsmessung eingebaut. Daher bekomme ich einen Akkustischen Alarm wenn der Akku z.B bei 22% Restwert ist und ich weiss dass ich landen muss. Jedoch d um das Dysplay abzulesen während dem Flug reicht es höchstens mal eine sekunde mal draufzuschauen wo du tendenziel etwa stehst. Jedoch sagen wir mal verschiedene Werte gezielt abzilesen würde mir nicht gelingen. Ich kann jedoch x-Verschiedene Akkustische Signale für diverse Spitzen oder Grenzwerte Programmieren, nur ob ich die dann während dem Fliegen auch wirklich erkenne wäre etwas anderes
Daher habe ich einfach meine "Tankuhr" und bin wirklich Happy damit, weil ich weiss, ich fliege solange wie der Akku was hergibt, ob ich Hart oder Soft Fliege spielt keine Rolle.

Gruss
Hansruedi

[dl7uae]

AW: Telemetrie vs. Alarming

Thx, Hansruedi.

Ja, um es noch mal mit einfacheren Worten zu umreißen, meine Auffassung zu der Sache:

Telemetrie überträgt Messwerte in einer analogen Range. Deren Anzeige erfolgt zwar ebenso und just-in-time, die Anwendung aber nutzt das gar nicht. Die Anwendung sind konfigurierbare Trigger, die einen Alarm auslösen, that's it.

Wenn ich also solche konfigurierbaren Trigger bereits am Ort der Entstehung der Messwerte habe (JLog), dann sollte irgendeine zu mißbrauchende Telemetriestrecke bestenfalls eine Alarmleitung für mich sein.

Nun noch just-in-time Werte zusätzlich via Telemetrie in ein Display beim Piloten zu übertragen, wäre ganz simpel Schmuck am Nachthemd, weil ich konkrete Werte eigentlich nur in forensischen Anwandlungen beäugen kann (hinterher), und dafür müssen die mit Bezug zu den konfigurierten Alarmen aufgezeichnet worden sein. Das macht JLog (und andere Logger), das macht aber normalerweise nicht das Ende einer Telemetriestrecke.

Ich hab' gerade so meine Auffassung an den genannten Kollegen geschrieben. Leider war das in EN, sonst hätte ich einfach DRag&Drop machen können.

[Asterix-007]

AW: Telemetrie vs. Alarming

Hallo Tom,

da hast Du ja ein interessantes Thema ausgegraben. Das wird bestimmt bis hin zum Glaubenskrieg führen... ;-)

Meine Meinung: Ich verfolge den Telemetrie-Hype schon eine ganze Weile, habe aber in meiner DSX 12 nichts dergleichen.
Zum Einen finde ich es eine schöne Sache verbrauchte Spritmengen, entnommene Ladungsmengen, Höhen, Geschwindigkeiten und z. B. GPS-Daten zu tracken, zu loggen und u. U. später auszuwerten.
Zum Anderen ist es für mein dafürhalten schlicht unmöglich die Daten auf einer Telemetrieanzeige (egal ob im Sender oder separater Box) sinnvoll zu verfolgen und auch (im Gehirn) live auszuwerten. Wenn ich fliege, gilt meine ganze Aufmerksamkeit dem Modell, egal wo der Propeller sitzt. Ich habe schon ein Problem den Timer bei einem Flugzeug zu erfassen, geschweige denn bei einem Heli. Das Auge braucht halt einen Weile um sich neu zu fokussieren und die Modelle stehen auch nicht in der Luft. Bis du dann das Modell in der Luft wieder gefunden hast, kann es schon zu spät sein. Außerdem hat man dann wieder einen "Informations-Overkill" wie in manchen Fahrzeugen. Da piept und bimmelt es bei jeder Gelegenheit und an jeder Ecke.

ich halte es jedoch für unabdingbar einige wichtige Werte (verbrauchtes Kerosin, entnommene Ladungsmengen und gefährliche Spannungslevel) zu übertragen und auch zu warnen.

Das einzig Vernünftige wäre dafür eine Sprachausgabe, welche frei konfigurierbar ist. Diese wäre dann idealerweise im Sender integriert und standardisiert! ;-) Ich bin gerade dabei einige Grundbetrachtungen, zumindest über die Sprachausgabe, anzustellen.

Denkbar wäre auch eine Art "Generalwarnung", welches nur einen Piep kennt und zum sofortigen Landen auffordert!

Alles andere ist Geschmackssache, ob im Modell oder Sender gespeichert, bzw. wieviel übertragen wird. Wenn es die ßbertragunskapazität hergibt, warum nicht auch beim Piloten.

Mal sehen, was hier noch für Meinungen kommen.

Ciao!
Ulf

[EcoRc]

AW: Telemetrie vs. Alarming

Ich würde mal sagen ein / zwei Realtime Alarme sind genug.

Es sei denn man fliegt FPV dann wäre zB: ein eingeblendeter künstlicher Horizont sicher ganz lustig in der Brille aber zwischendurch auf seinen Sender schauen wer macht das schon ?

Wenn du FrSky Telemetrie verwendest dann kannst du neben den analogen Spannungenswerten die du mit Alarmen versehen kannst nebenbei auch von deinem yP bequem serielle Daten senden an die Funke die dort wiede seriell rauskommen. Das verwende ich für einen künstlichen Horizont inclusive GPS Infos. Nur hab ich diese Sachen derzeit noch am Laptop (nicht sehr praktisch auf dem Flugplatz )

mfg,
Stefan

PS: Kostet ja nicht die Welt

http://www.giantcod.co.uk/frsky-24ghz-futaba-combo-module-receiver-p-404882.html

[Gerd Guzicki]

AW: Telemetrie vs. Alarming

Beide Techniken haben Ihre Vor- und Nachteile. Ich setze Sie seit Jahren ein und bin für mich beim Telemetriesystem hängen geblieben.

Der Blitzer oder Buzzer ist billig und durchaus funktionell. Ich habe jedoch das Problem damit, dass meine Augen praktisch ab Flugbeginn versuchen, den Bereich, wo die LED montiert ist, ständig zu fixieren, obwohl dort ja normalerweise den ganzen Flug über nichts zu sehen ist. Aber trotzdem, das Gehirn befiehlt dem Auge irgendwie, ständig diese Stelle des Helis anzuschauen, was natürlich die Konzentration auf den Flug stört.

ßhnliches passiert mit Piepern. Das Ohr versucht in dem Heli-Geräusch dauernd einen Piepton zu finden, was der Konzentration auch nicht wirklich förderlich ist.

Dann hatten wir mal ein Telemetriesystem im Programm, das ich "Sputnik" nannte. Etwa im 10-Sekunden-Takt wurden per 433 MHz Pieptöne rübergeschickt, die die Gesamtspannung darstellten. Bei Unterschreiten von 3.6V piepte es zweimal hintereinander, bei 3.4 Volt dreimal. Man hatte einen kleinen Ohrhörer im Ohr, der so über den Ladestand informierte. Allerdings störte das die Konzentration so sehr, das ich nur abraten kann von so etwas. Ausser natürlich, man ist Taxifahrer und so einen kleinen (Bluetooth-)Mann im Ohr gewohnt.

Am besten finde ich daher ein optisches Telemetriesystem. Man KANN sich informieren, wenn es die fliegerische Situation gerade erlaubt und muss nicht mit nervlicher Anspannung auf die Auslösung eines Alarmes warten. Ob jetzt aber ein in die normale Funkübertragung integriertes System ala Jeti, Hitec etc. besser ist oder ein autonomes System, muss jeder fallweise für sich selbst entscheiden. Bei mir war ausschlaggebend, dass das Jeti-System sich nicht mit meinen Sender ohne größeren Aufwand verheiraten liess und ich ausserdem etliche Fasst-Empfänger im Einsatz habe.

[dl7uae]

AW: Telemetrie vs. Alarming

Gerd, danke!

Aber drahtlose Alarmgebung ist ja nicht gleichzusetzen mit Telemetrie.
Bei Telemetrie werden Messwerte übertragen und am Ende auf Alarme ausgewertet.
Hier geht es darum, dass ja schon die Auswertung zwangsläufig im Modell ist, im Logger, ich muss also nur noch den Alarm an den Mann bringen.

Nun scheint hier bei dem Menschen, der da gerne was hätte, das Kleiner-Finger-Ganze-Hand-Prinzip zu wirken. Eben war es noch der Alarm, und schon haben wir gleich noch die Messwerte Logger->ßbertragungsstrecke. Dagegen wehre ich mich, a) eben weil eine zweite Alarmauswertung nach der ßbertragungsstrecke hier Redundanz wäre, und b), weil ich zwar auch so spielerisch veranlagt bin, Messwerte im Display des Senders gut zu finden, das aber praktisch eher nebenrangig ist neben dem Triggeralarm darauf.

[Yvie]

AW: Telemetrie vs. Alarming

Hallo,

ich fliege nun seit einem Jahr mit Jeti Telemetrie,

am anfang war es natürlich sehr interessant alles im Modell zu überwachen und im Blick zu haben, aber es lenkt eben doch sehr vom Fliegen ab.

Das einzige was ich wirklich brauche ist die Anzeige der entnommenen Kapazität des Flugakkus und den dazugehörenden Alarm. Dabei ist mir die Anzeige der bisher entnommen Kapazität in der Box fast genau so wichtig wie der Alarm, da ich so durch eien kurzen blick aufs Display jederzeit abschätzen kann wieviel Flugzeit mir noch bleibt.

Ideal währen für mich ein Vibrationsalarm für die Kapazität und ein akustischer Alarm für die nicht gar so wichtigen Dinge wie Temperatur oder ähnliches.
Denn ich habe die Erfahrung gemacht, dass man die vielen unterschiedlichen Tonfolgen die für die verschiedenen Schwellenwerte festgelegt werden können, während des Fluges garnicht unterscheiden kann.

Gruß

[Squenz]

AW: Telemetrie vs. Alarming

Nun scheint hier bei dem Menschen, der da gerne was hätte, das Kleiner-Finger-Ganze-Hand-Prinzip zu wirken. Eben war es noch der Alarm, und schon haben wir gleich noch die Messwerte Logger->ßbertragungsstrecke. Dagegen wehre ich mich, a) eben weil eine zweite Alarmauswertung nach der ßbertragungsstrecke hier Redundanz wäre,...

Mag sein, dass ich mich mit meinem Unwissen jetzt aus dem Fenster lehne aber die Redundanz von der Du sprichst wird z.b. bei der DX8 doch eigentlich immer von nöten sein. Der Alarm wird von der 8er ja auch nur dann ausgelöst wenn ein zuvor definierter Schwellwert überschritten wird - und das passiert innerhalb der Sendersoftware. Allerdings denke ich nicht, dass man dazu "reale Echtzeitdaten" verarbeiten müsste bzw. kann ich mir vorstellen, dass dies die Sache ungleich komplizierter machen würde.

interessierte Grüße

Markus

[Gerd Guzicki]

AW: Telemetrie vs. Alarming

Hallo Tom,

das ist schon klar. ich wollte das eben nur von der fliegerischen Seite etwas beleuchten.
Folgendes ist mir auch noch aufgefallen, da mein Iisi über mehrere Anzeigevarianten verfügt:
Das obere Bild zeigt eine Balkenanzeige der Kapazität, ähnlich einer überdimensionalen Tankuhr. Das zweite ist eine Art Universalanzeige mit verschiedenen Informationen.




Interessant ist, dass ich erst dachte, dass bei der Balkenanzeige die Informationserfassung "auf einen schnellen Blick" am einfachsten ist. Aber Pustekuchen: Das Auge braucht wesentlich länger zur Erfassung des Balkens, als wenn nur ein einzelner Wert erfasst wird. Das Modell ist deutlich länger unbeaufsichtigt. Bei der zweiten Anzeige ist die Ah-Anzeige oben rechts, da der Blick ja von oben kommt. So lässt er sich am schnellsten erfassen. Das Schöne an dieser Anzeige ist, dass man schauen kann, aber eben nicht muss. Piepen tut es ja so oder so, wenn die voreingestellte Entnahmegrenze erreicht ist.
Irgendwie erinnert mich dieser ganze Datenwahn an unsere Navis. Es scheint wohl mittlerweile irgendwie zum Leben zu gehören, dass man jeden M... wissen muss.
Um dem Vorredner zuzustimmen: Die Restkapazität ist das einzig Wichtige während des Fluges, mehr braucht man nicht.

[dl7uae]

AW: Telemetrie vs. Alarming

Markus, "Redundanz" hier deshalb, weil ja der Logger (JLog) bereits Alarme bildet.

Allerdings muss man nun den Alarm von JLog via TM1000 zur DX8 übertragen, als virtuellen Messwert, - und darauf sogar in der DX8 einen Alarm bilden, sonst gibt die ja keinen Piep von sich.

Allerdings wehre ich mich, daher "Redundanz", dagegen, nun gleich noch tonnenweise Messwerte aus dem Logger in die DX8 zu schieben.

OK, die nächste Hardwaregeneration des JLog wird genug Speicherplatz für weitere Spielereien haben, JETI Telemetrie-Protokoll kommt auf jeden Fall rein, vielleicht sogar noch in den bisherigen JLog, wenn ich noch irgendwie Platz schaffen kann.

Die ßbertragungsstrecke von Spektrum, derzeitig TM1000-->DX8, aber dafür zu benutzen, erfordert vermutlich eine Krücke (Sensoren emulieren, komische Anzeige im Sender), die mich das Ganze mit Spektrum anzweifeln lässt. Selbst wenn man das "Internal DATA"-Interface anzapfen könnte oder den "X-Bus" (Zukunft?) benutzen könnte, bliebe die proprietäre und unflexible Gestaltung der Anzeige fremder Daten im Display der DX8.

-----
Alles klar, Gerd.

[Stephan Lukas]

AW: Telemetrie vs. Alarming

Hallo Tom,

also es wird um dieses Thema wirklich vllt. einen Hype geben, da hast du schon Recht...

Ich selbst schaue nur auf den Sender, um den Anfangs-Pitchwert bei der Auro kurz mal im Blick zu haben, sonst würde das auch mich nur vom Fliegen zu sehr ablenken

Zum Thema Kapa oder Spannung habe ich mich schon genug ausgelassen, daher von mir einfach der Vorschlag Alarm bei Unterschreitung einer Schwellspannung, damit noch genug Zeit zum landen bleibt, die Kapa ist unwichtig (siehe auch Gerd Giese)...

edit: Diese Schwellspannung sollte man jedoch schnell anpassen können, da sich unterschiedlich alte Akkus ja diesbezüglich sehr unterschiedlich verhalten,

Grüße Stephan

[dl7uae]

AW: Telemetrie vs. Alarming

Ja, Stephan, ist doch aber alles längst drin.

[dl7uae]

AW: Telemetrie vs. Alarming

So, OK..., mein "Penetrator" hat die Hosen runtergelassen: Er mag eben die Livewerte im Display, punktum.

Letztendlich wird so die Masse denken..., es ist eben alles Spielzeug für große Kinder..

Mit JETI ist hier alles klar, no problem, und schön flexibel im Display.

Dass man für dasselbe mit Spektrum Telemetry den TM1000 vergewaltigen muss, indem man Sensoren emuliert, - und dann auch gleich noch mal alle Hühneraugen beim Display der fremden Daten in der DX8 zudrücken muss, - will er verschmerzen..

Ich bevorzuge dann aber eine Hardwareoption, ein kleines "STI" ("Spektrum Telemetry Interface"), sprich, eine MCU, die per I2C am Logger hängt und nix anderes macht, als Sensoren zum Verarschen des TM1000 zu emulieren. ---- JETI Telemetrie würde direkt aus dem Logger kommen.

[speedy610]

AW: Telemetrie vs. Alarming

Hallo Tom,

jetzt verstehe ich so langsam was du meinst. Deine Idee ist, dass kein zusätzliches "Interface" gebraucht wird. Jetzt z.B. mit dem iisi wird ja im Cockpit der Wert des Akkus programmiert und die Datenaufbereitung geschieht auch dann im Cockpit, also bereits unten beim Pilot. Was du machen willst, ist im Modell einen Alarm generieren, wo auch immer, und nur den Alarm runter zum Sender schicken. Verstehe ich dich so richtig? Dieser Ansatz ist auch sehr Interessant und würde die gesendete Datenmenge natürlich wesentlich reduzieren. Auch bräuchte ich nicht ein starkes Interfase in der Motorenleitung um die Amps messen zu können. Ja, das gefällt mir auch sehr gut ;-) Nur wie wird das z.b. Futaba oder andere Brands-Kompatibel? Willst du auch mit einem Display am Sender Arbeiten?

Gruss
Hansruedi