OpenTx und Fremdmodul Telemetrie - Status Quo

Hallo,

ich denke die Überschrift sagt alles.
Wie schaut es bei OpenTx aktuell aus? Welche Telemetrie kann von welchem Hersteller verarbeitet und dargestellt werden?
Sicher ist das irgendwo in den Tiefen anderer Foren vergraben aber hier wäre ein schöner Platz für eine Zusammenfassung.
Gerne auch eine Art Projektstatus weil sicher viele Einzelne das Problem individuell angehen und möglicherweise ihre eigene Lösung suchen.

Soweit ich das bisher beobachten konnte liegt ein Hauptproblem bisher darin, das die am Fremdmodulport zur Verfügung stehende UART (und jede aktuelle TM bedient sich dieser) noch nicht wirklich unterstützt wird.

Wenn man mal ehrlch ist, bedeutet Telemetrie eigentlich überall das gleiche, weil immer die gleichen Messgrößen erfasst werden (Höhe, Vario, Spannung, Strom, Temperatur etc.). Hier wäre doch ein Ansatz das auch generisch zu behandeln und dazwishcen nur den entsprechenden Protokollumsetzer zu schalten mit Zuweisung Eingang zu Ausgang. Klingt einfach, ist es aber sichen nicht.

Eine breite Hardware / Softwareunterstützung ist ja einer der Grundpfeiler von OpenSource. Daher die Frage.
Ich persönlich kann und werde mit FrSky nix anfangen, weil ich nicht zweigleisig fahre und dies auch nicht wirklich praktikabel ist, weil sonst 2 Empfänger in ein Modell müssten.

Gruß und ein schönes WE

Onki

In Gebrauch habe ich einen Unisens-E, funzt mit den X-Empfängern einwandfrei.
Ein "Airspeed-Sensor" liegt schon rum, auf ein GPS-Modul von Bumsgut warte ich noch. Da alles über S-Port in Reihe geschaltet wird, erwarte ich damit keine Probleme.

Hallo Carsten,

hier geht es nicht darum, welche Fremdsensoren mit FrSky funktionieren sondern welche Fernsteuer-Fremdsysteme (also z.B. Spektrum, HoTT, MLink, Jeti) auch Telemetrie in OpenTx mit der Taranis, X9E... auswerten können (oder zukünftig werden).

Gruß
Onki

onki schrieb:

hier geht es nicht darum, welche Fremdsensoren mit FrSky funktionieren sondern welche Fernsteuer-Fremdsysteme (also z.B. Spektrum, HoTT, MLink, Jeti) auch Telemetrie in OpenTx mit der Taranis, X9E... auswerten können (oder zukünftig werden).

Zum Vergrößern anklicken....

Hallo Onki,
ich denke das können nur die Macher von OpenTX beantworten. Die Frage ist, ob sie das wollen und ob die Hersteller den Code zur Verfügung stellen.

http://fpv-community.de/showthread.php?71647-X9E-und-Multiplex-M-Link-Modul-HFMG1-HFMG2-HFMG3

http://openrcforums.com/forum/viewtopic.php?f=96&t=7275

Gruß KH

Hallo,

das sieht doch schon mal gut aus. Ich dachte mir schon, dass der Teensy als "Übersetzer" zum Einsatz kommt, weil der echt klasse ist.
Vielleicht hat die Horus ja mehr Dampf und der Teensy wird überflüssig.
Dann kann man ja schon mal bei MLink einen Haken darn machen, zumindest einen kleinen.
Bin gespannt ob es auch Implementationen für weitere Systeme gibt.

Gruß
Onki

Nur hält sich die Begeisterung auch speziell für M-Link -> Taranis m.E. in Grenzen. Leider!

Anscheinend wird lieber fertig gekauft. Und ich kann dann sehr gut verstehen, dass die Entwickler dann recht schnell hin schmeißen.

Gruß KH

So wie ich es verstanden habe, sind die HW-Schnittstellen ja prinzipiell in den FrSky-Sendern vorhanden, nur werden die Protokolle aktuell nicht von OpenTX unterstützt.
Da aber schon Bastellösungen zur Protokollumsetzung im Umlauf sind, die sogar auf einem Arduino laufen, sollte das ja auch direkt im Senderbetriebssytem möglich sein.

OpenTX ist stark von Nutzerwünschen getrieben, ich denke wenn erst mal die Horus auf dem Markt ist, wird es eine Menge Umsteiger geben, die sich sowas wünschen...

Kann man auch andersrum sehen. Wenn's z.B. ne Protokollimplementierung für ein Jeti-Modul gäbe, dann würden einige anfangen zu überlegen, insbesondere bei der anrollenden Horus. Nach Aussage eines OpenTx-Programmierers bräuchte es dazu nur einer Parserprogrammierung. Allerdings sind die wenigen OpenTx-Programmierer zur Zeit mehr als ausgelastet und es gibt demnach zur Zeit bei denen keine freie Kapazität. Vielleicht ändert sich das mal, wenn erstmal die OpenTx-Version für die Horus fehlerfrei lauffähig und freigegeben ist. Wenn also jemand sowas programmieren kann und will, könnte er sich da sicher einbringen.

Gruss
Franz

Hallo,

da schließe ich mich deiner Meinung an Franz. Ich bin z.B. auch an einer Jeti-TM-Implementierung interessiert.
Ich habe zwar mit ner mc22s (Jeti Modul drin) einen sehr guten Schülersender, aber die TM-Ausgabe über die Jetibox ist echt grenzwertig.
Varioton geht auch nicht, und das ist nunmal ein zentrales Thema beim Segelfliegen. Daher muss ich immer meine DC-16 hergeben, wenn ein Jugendlicher mal meinen Sharon für einen Wettbewerb nehmen will. Zudem hätte ich gern - auch wenn ich seither immer mit Handsendern auf Kriegsfuß stehe und irgendwie zu dämlich bin , die richtig zu steuern (bin halt kein Daumensteuerer) - einen brauchbaren Handsender als Zweitsender, um den immer im Auto zu haben und den auch mal im Gebirge in den Rucksack zu werfen und auf dem Gipfel zu fliegen. Das geht mit der doch recht üppigen DC-16 nicht und die Jeti-Handsender sind mir dazu zu teuer und für die anstehende Nutzung nicht wirklich wirtschaftlich. Daher schiele ich auch auf die (der, das?) Horus, weil die noch in meinem Budget wäre und vernünftige Qualität liefert (zumindest dem Anschein nach). Und ich denke es geht vielen so.
Bin mal gespannt, wie sich diese Geschichte weiterentwickelt. Leider hab ich es mit dem programmieren nicht so, ich tu mich schon schwer, dem Teensy seine neue Rolle als Jeti-Stromsensor beizubringen.

In einem der anderen Foren wurde berichtet, dass zumindest die Befürchtung besteht, dass die Hardware diesen Parser womöglich nicht geschultert bekommt und deshalb auf einen externen Teensy zurück gegriffen wurde. Woanders stand mal sinngemäß, das die Unterstützung der am Ext. Modul liegenden UART noch sehr rudimentär sei. Mal abwarten, wie sich das Ganze nun gestaltet. Das die Programmierer gerade am Anschlag sind, kann ich Aufgrund der in den Startlöchern stehenden neuen Steuerung durchaus nachvollziehen.

Gruß
Onki

Hallo Jungs,

ich bin auch einer der angehenden, mit vielen Fragezeichen durch die Welt googlenden Arduino-Jüngern auf der Suche nach DEM Protokoll-Konverter.
Aufgesprungen bin ich erstmal auf den Fred im RC-Network betreffend der Bibliothek zur Jeti-Telemetrie. Dazu hab ich erstmal den Ardu in zwei Versionen (mini und Uno) und zusätzlich einen Baukasten von Allnet.

Da klappte zumindest die Textänderung in der Senderseitig am Duplex-TG2 angeschlossenen alten Jetibox.
In der aufkeimenden Euphorie hab ich dann den Fred im FPV-community betreffend der Umsetzung der MLink-Telemetrie IN DIE Taranis gefunden und direkt ein Teensy geordert.
Damit hab ich noch ein "kleines" Problem, aber in kleinen Schritten mit Unterstützung von Kalle und Dieter und geebayter Messtechnik wird das was.

Mein Problem ist eigentlich mein gefährliches Halbwissen in der Ardu programmierung. Wenn sich hier eine breitere Basis an Leuten mit dem nötigen Sachverstand kurzschliessen könnten, wäre die Implementierung ein "Klaks", der Run auf die Horus wäre dann vermutlich der berühmte Tropfen.

Die Implementierung in das OTX halte ich für nicht sehr sinnvoll. Vermutlich werden zumindest die Prozessoren in der Taranis damit überlastet und die Basis an X9E ist noch zu klein. Ganz zu schweigen von den anderen OTX-Sendern.

Die Verwendung von Teensys und Co ist wesentlich flexibler und hat durch deren einfacher Verfügbarkeit und dem niedrigen Preis schneller eine Programmiererbasis als die Einarbeitung in OTX oder der zusätzlichen Belastung der OTX-Entwickler.

Nur: Wie begeistert man die Leute?
Bei uns im Verein sind einige, welche nur darauf warten, daß die Horus verfügbar wird und die aktuellen Systeme Hott, Jeti und Mlink in das System-Display eingebunden werden können. Aber selber was proggen ist zu kompliziert. Meint man, und ich kann es im Moment nur bestätigen.

Mit der aktuellen Teensy-Schaltung sollten wir auf jeden Fall schonmal hardwareseitig weiterkommen.


Grüsse, Gruni

Hallo,

ich hadere derzeit auch mit meinen Programmierkünsten. In der Ausbildung damals sind wir leider nicht über kleine TurboPascal-Programme herausgekommen und das ist schon 30 Jahre her.
Wie der Protokollkonverter dann aussieht ist ziemlich egal. Entweder als OTX Feature oder als Tennsy-Lösung etc. Sofern sie so gestaltet ist, dass ein halbwegs begabter Mensch damit seine Lösung verwirklichen kann ist das Sicher kein Thema.
Vereinfacht gesagt geht es ja darum, einen Eingangs-Datenstrom vom UART1 zu empfangen, puffern und auszuwerten und den dazugehörigen Werten des Ausgangsdatenstrom anzupassen. Dieser wird dann via UART2 an die OTX-Kiste gesandt und als FrSky Datenstrom vorgegaukelt.

Gruß
Onki

Hi,

hat irgendwer einen Link zum OTX-Protokoll und evtl. vom HOTT-Modul zum Display ?
wenn man das hätte, sollte doch der Rest kein Problem sein.
Einen Schnittstellenkonverter sollte man doch hinbekommen.

Hallo Kai,

Jeti hat sein Protokoll offengelegt:
http://www.jetimodel.com/de/Telemetrieprotokoll/

HoTT verlangt AFAIK ein NDA dafür.

FrySky bzw OTX sollte das hier sein:
https://github.com/TauLabs/TauLabs/wiki/User-Guide:-FrSKY-S.PORT-telemetry

Gruß
Onki

Hi Onki,

hier ist nicht das Protokoll zwischen Sensor und Empfänger gemeint !
Hier st das Protokoll zwischen HF-Modul und Sender gemeint !
z.B. wenn man in der Taranis ein HOTT oder Jeti-Modul verwendet, und dann die Telemetriedaten in den Sender zur Auswertung / Anzeige überträgt.
Ich glaube nicht, dass dies die gleichen Protokolle sind.

Ach Gruni, auch hier

Beim Mlink -> FrSky Konverter geht es inzwischen recht gut.

Höhe, Vario, RX Spannung, Strom, Akku Spannung (mit kleinem Problem) gehen.

NUR. Ich hatte die (anscheinend falsche) Vorstellung.
MPX ist recht verbreitet und die Taranis inzwischen auch. Die HFMG3 Module wurden für ein paar Euros vertickt.

Man kann sich da vor Mitstreitern nicht mehr retten. Ja, von wegen! Dieter ändert den Code, ich teste und Gruni hat Anlaufschwierigkeiten - that's it

Ach noch was. Bei Jeti könnte ich auch noch mitmachen
Ne auf Jeti umgebaute Royal Pro steht hier auch noch rum. Müsste mal nach nem HF Modul für die Taranis schauen .....

Gruß KH

k_wimmer schrieb:

Hi Onki,

hier ist nicht das Protokoll zwischen Sensor und Empfänger gemeint !
Hier st das Protokoll zwischen HF-Modul und Sender gemeint !
z.B. wenn man in der Taranis ein HOTT oder Jeti-Modul verwendet, und dann die Telemetriedaten in den Sender zur Auswertung / Anzeige überträgt.
Ich glaube nicht, dass dies die gleichen Protokolle sind.

Zum Vergrößern anklicken....

Bin selber kein Programmierer, aber nach meinem Verständnis gibt's hier eine bereits fertige Library zur Umsetzung von ankommenden Telemetriedaten in S-Port-Daten, die einem OpenTx dann in verwertbarer Form zur Verfügung gestellt werden (so als kämen diese von FrSky Smart-Port-Sensoren => http://www.rcgroups.com/forums/showthread.php?t=2245978

Entweder müsste also ein Umsetzer dies direkt als Unterroutine in OpenTx selber tun oder aber ausserhalb OpenTx und dann Einspeisung über S-Port-Signaleingang z.B. hier =>

Direkt in post #1 dort steht

"... or those having Tarains radios or other system capable of receiving FrSky S-Port telemetry data I've created a library, that allows to emulate the FrSky S-Port sensors using Arduino compatible Teensy 3.x board or 5V/16MHz 328P based boards (e.g. ProMini, Nano, Uno)."

Und wie Onki schon schrieb "...welche Fernsteuer-Fremdsysteme (also z.B. Spektrum, HoTT, MLink, Jeti) auch Telemetrie in OpenTx mit der Taranis, X9E... auswerten können (oder zukünftig werden)."

Und zu guter Letzt, schau dir das mal an https://github.com/opentx/opentx/wiki/Taranis-serial-port

Hallo,

Super - nun wissen wir ja wo wir die TM-Daten einspeisen und mit welchen Einstellungen.
Fahlt nur noch eine beschreibung des Formates. Oder ist das diese S-Bus Geschichte, die von FrSky/OpenTx verwendet wird?
Aber wenn MLink ja schon klappt haben "wir" C3PO ja schon Badisch -> Chinesisch beigebracht.
Dann fehlt noch die Schwäbisch -> Chinesisch sowie die Tschechisch -> Chinesisch Implementierung .

Gruß
Onki

S-Port ist der Telemetriebus, nicht mit S-Bus für Servos verwechseln!