Telemetrie vs. Alarming

[Heli-Ralle]

AW: Telemetrie vs. Alarming

ich versuche mir gerade vorzustellen, wie man während des Fluges mit dem IISI Cockpit umgeht und dabei einen Handsender in der Hand hält.

Müßte ich schon irgendwie am Sender temporär montieren können.
Einfach das Cockpit um den Hals hängen und auf den Piepser warten ist für mich keine Lösung.
Wie macht Ihr das ?

Gruß
Ralle

[speedy610]

AW: Telemetrie vs. Alarming

ich habs so Montiert. Habe den Winkel jedoch nochmals etwas Abgeflacht...

Gruss
Hansruedi

[Heli-Ralle]

AW: Telemetrie vs. Alarming

prima gelöst und sieht auch noch schick aus !

Danke !

Gruß
Ralle

[kermitkong]

AW: Telemetrie vs. Alarming

hi all,

also ich baue gerade ein Telemetrie-System, was eine Menge deiner Probleme löst.
Es ist aber eben auch eher was "fettes", denn es können bis zu 24 Sensoren aller Art angeschlossen werden. Ein grafisches Touch-Display sorgt für die einfache Steuerung.

schaut einfach mal auf: http://www.flightcommand.de

gerne beantworte ich Fragen, oder nehme Verbesserungsvorschläge entgegen.

Gruß
Kermit

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?!!

...........

[dl7uae]

AW: Telemetrie vs. Alarming

@KK, danke für den Link, nur habe ich da auf den ersten Blick nix Konkretes finden können.:dknow:

@All
Ich habe mich wohl etwas missverständlich ausgedrückt..
Es geht hier um einen Sonderfall: Ein Logger bildet bereits konfigurierbar Alarme, die müssen nur noch gemeldet werden, und man will das gerne via eine vorhandene Telemetriestrecke.

Dann stellt man (mein "Penetrator") im Weiteren fest, dass man trotz der eigentlich praktisch nur genutzten Alarme trotzdem gerne ein Livedisplay relevanter Werte hätte, auch wenn man da nicht draufgucken kann während des Fluges, auch wenn man keine Datenaufzeichnung hat, die aber sehr wohl der Alarm meldende Logger macht, also Aufzeichnung von Messwerten UND Alarmen im Bezug zueinander.

Ein Argument lautet auch, dass das Auswerten von Triggerschwellen im Sender, also das Einstellen der Alarme hier bequemer sei, weil man dafür keinen PC brauche wie beim Logger. Das stimmt soweit in dem Falle, es sei denn, man hat mehrere SD-Karten mit vorbereiteten Setups dabei (für JLog). (Andere Logger haben aber Terminals dafür im Angebot.)

Hauptgrund ist aber einfach der "Spieltrieb", die Liveanzeigen haben zu wollen, auch, wenn einem dabei Informationen flöten gehen, weil im Gegensatz zum Logger nicht aufgezeichnet wird. (ßbrigens muss ich hier auch das Data Processing am Anfang oder Ende einer proprietären Telemetriestrecke mit Fragezeichen besetzen, z.B., ob diese Daten einer Integration unterzogen werden, oder nicht. Ein Alarm-Triggering ist eben nicht nur AN/AUS.)

Nun, a) fühle ich mich nicht berufen, gegen Anwendungen zu missionieren, nur weil man beim Spielen damit praktisch behindert ist, das ganze Hobby ist "Spiel", --- b) reden wir dabei von zwei verschiedenen Ansätzen aus unterschiedlichen Ecken, einmal dem Ansatz der Logger-Anbieter, einmal dem der Fernsteuerfritzen. Eine integrative Lösung wäre natürlich wünschenswert, doch gibt es dabei bestimmt Hemmschwellen der Spezialisierung. Im Falle eines Spezialloggers wie JLog sowieso. (Außerdem geht es um möglichst ganzheitlichen Profit.)

Somit war mein Thema eigentlich nur, wie reine ON/OFF-Signale und evtl. "wackelnde" Livewerte in eine jeweils proprietäre Telemetrie einzuspeisen? Und im Umkehrschluss, dass ich die Livewerte hier eigentlich nicht übertragen muss, für eine tatsächlich nutzbare Anwendung.

"Proprietät" ist das Stichwort: Jeder kocht sein Süppchen dabei. Ein Microsoft verdonnert man zu Strafen, weil nicht vorhandene oder nicht offen gelegte Schnittstellen die Integration fremder Produkte behindern, - hier betreibt man das im großen Stil.

JETI legt die Schnittstelle auch nicht auf die Straße, ist aber offen, und man ist sich auch dessen bewusst, dass alle Welt es nutzen kann. Das ist natürlich sicherlich auch der Tatsache geschuldet, dass JETI bisher als Komponentenanbieter auftrat, aber auch der, dass deren Display als eierlegende Wollmilchsau konzipiert wurde.

Spektrum nun fährt die Schiene des eigenen Topfes, in den man sich nicht reingucken lassen will. Das wird sicherlich auch jeder weitere Anbieter von Telemetrie im Zusammenhang mit deren jeweiliger Fernwirktechnik machen.
Es geht dabei nicht nur um das Einspeisen von zu übertragenen Daten in die Telemetriestrecke, sondern vor allem auch um Darstellung und Auswertung an deren Ende, was außer bei JETI wohl immer völlig proprietär und unflexibel nicht-offen ausfallen wird, siehe Spektrum.

[JMalberg]

AW: Telemetrie vs. Alarming

Für mich muss ich da stark zwischen
1. Daten protokollieren
und
2. Alarm auslösen
unterscheiden.
Wie beides mir übermittelt/mitgeteilt wird ist mir eigentlich erst mal wurscht; ob per Telemetrie oder per visuelles Signal am Heli (von Audiosignalen halte ich nix). Die Telemetrie ist daher nur ein Vehikel zur Nachrichtenübermittlung; erst mit dem Hinweis von Gerd über die Fixierung von "Signalstellen" macht es Sinn Telemetrie zu nutzen.

Je nach Anwendung im Boot, RC-Car, Segler, Flächie oder RC-Heli kann ich sowieso nicht irgendwelche Displays beobachten und fixiere auch wie Gerd es beschrieb nicht gerne ständig einen Alarmsignalpunkt am Heli. D.h. irgendwelche Daten interessieren mich nur nach dem Fliegen/Fahren/Schwimmen usw.
Ein Alarm muss daher mMn mir per taktilem, visuellem oder auditivem Signal mitgeteilt werden oder sogar unmittelbar eine Funktion am Sender auslösen. Irgendwelche Displays mit vielen Daten kann ich nicht gebrauchen.

[Taumel S.]

AW: Telemetrie vs. Alarming

gerne beantworte ich Fragen, oder nehme Verbesserungsvorschläge entgegen

Hmm, ich kann die Beschreibung deines Flightcommands nicht finden, ehrlich gesagt!
Hast du einen genaueren Link?

[stefimat]

AW: Telemetrie vs. Alarming

Das ist der PUNKT:

Für mich muss ich da stark zwischen
1. Daten protokollieren
und
2. Alarm auslösen
unterscheiden.
...

GENAU!!

Da ich selbst ja schon eine ganze Weile verschiedenste "Themen" in meinen
Flügen analysiert habe,
kann ich aus meiner Erfahrung Dir Jürgen ganz besonders zustimmen!

Das eine hat nur mittelbar mit dem anderen zu tun!

Wichtig ist sicherlich das Alarm auslösen für gefährliche "Flugparameter"

Bei uns E-Fliegern meist die Spannung der (einzelen) Zellen! (sonst geht bald gar nichts mehr )

Klar ist auch, daß die Aufmerksamkeit bei einigermasen anspruchsvollen Modellen,
und meist da ist eben die "Info zum richtigen Zeitpunkt" auch wichtig,
so stark am Modell hängen muss (soll),
daß eine "beiläufig" aufnehmbare Warnung zum Piloten gebracht werden muss, damit sie auch sicher ankommt.
Sinnvoll ist dabei meist akustisch VOR ORT, da das Hören immer aktiv ist.

Ich selbst habe mit Blitzern, Piepsern am Modell etc. schon die Erfahrung gemacht,
daß ich diese nicht immer sofort wahrnehme! Außer ich konzentriere mich aussließlich darauf, wie es Gerd schon beschrieben hat.
Das will ich aber meist nicht,
weil ich entweder ein anderes "Thema" wie
- Figuren fliegen,
- Testabläufe koordinieren, oder
- einfach nur Spaß haben am Fliegen
in den Vordergrund rücke!


=> Alamieren MUSS sicher und ganz nebenbei funktionieren.
===========================================

Toms Idee, auch auf der ßbertragungsstecke der Telemetrie die
Trennung zwischen
1. Daten protokollieren
und
2. Alarm auslösen
einzuführen,
finde ich sehr gut durchdacht, denn

zuwas Daten (die Loggs) aufwendig irgendwo hin transportieren, wenn diese
sowieso erst später ausgewertet werden?

Diese vielen Daten nur zum "eventuellen" visuellen ablesen während dem Flug
über teure Technik zu transportieren halte ich für nicht sinnvoll.

Es verleitet sogar eher dazu, mal zur Info wegzuschauen....
mit der Folge... kann sich jeder selbst vorstellen.


Deshalb:
=======

Klares "Ja" für ein Konzept,

das

- nur noch wirklich benötigte Daten zum Piloten selbst bringt!

Diese "Reduzierung" macht es eventuell möglich,
- Herstellerübergreifend zu arbeiten,
- und oder drückt den Preis der dann nur noch "auf das wesentliche" reduzierte Telemetrie so,
daß diese dann in jedem Modell eingesetzt werden kann,
und somit zu einem zuverlässigen (da immer vorhanden) Helfer / Warner wird!

CU l8er Stefan