OpenTX - Multiplex MLINK Konverter

Hallo,
In Zeiten von 3D Druckern wäre es generell möglich ein passendes Gehäuse zu drucken!
Würde ein anderes Gehäuse helfen oder scheiterte an der Größe der Platine?
LG Roland

Immer die gleichen treuen Seelen hier.

Die Größe der Platine ist nicht das Problem.
Ich muss mir das die nächsten Tage mal genau anschauen, wo es da hakt.
Das HFMG2 hat zwei GFK Streifen, die nur der Befestigung dienen.
Vielleicht liegt das Problem ja da und lässt sich mit einem Loch in diesen Streifen beseitigen.

Ich werde berichten...

Wo wir wieder beim Problem der "Modifikation " wären und der Befürchtung rechtlichen Schutz zu verlieren.
Gleiches gilt für gedruckte Gehäuse.
Gibt es diesbezüglich fundierte Kenntnisse?

Hallo zusammen,

hier mal ein Bild, wie das HFMG2 in der X10S eingebaut war.
Es schwebt sozusagen über dem Knüppelaggregat, mit dem es dann bei extremen Ausschlägen in die Ecken kollidiert.



Sei's drum, ich habe jetzt das FrSky OS Installiert, mit dem ich ohnehin mal ein bisschen spielen wollte.
Müssen halt meine drei anderen FrSky Sender erst mal für OpenTX herhalten.

Dank dir für das Bild, Reinhardt.

Setze hier mal ein Bild rein, wie es ohne MPX Modul ausschaut.

Quelle: https://alofthobbies.com/horus-x10.html

Hast du kein HFMG3 mehr übrig?

Grüße KH

kalle123 schrieb:

Hast du kein HFMG3 mehr übrig?

Zum Vergrößern anklicken....

Doch, aber da gibt es halt das Problem, wo man den Konverter anschließen soll.
Außerdem wollte ich, dass man den M-Link Umbau von außen nicht sieht.

Hallo zusammen,

nachdem meine X9E jetzt wieder mit M-Link Modul und Konverter ausgerüstet ist,
habe ich mir die Frage gestellt, ob man am Konverter was verbessern könnte, aber mir ist nichts eingefallen.

Außer folgendes:

Vielleicht werde ich die zwei Versionen (mit und ohne FrSky IDs) zu einer zusammenfahren.
Es sind codemäßig nur recht überschaubare Unterschiede, ein Zusammenfahren wäre daher ziemlich einfach.

Man könnte einfach einen der Eingangs-Pins zum Umschalten verwenden:
- Pin offen: FrSky IDs werden nicht verwendet.
- Pin auf Masse: FrSky IDs werden verwendet.
Die Codierung für die Verwendung von FrSky IDs wäre dann über eine einfache Drahtbrücke leicht machbar.

Wesentlich eleganter wäre es natürlich, die Betriebsart modellspezifisch umschaltbar zu machen.
Im M-Link Datenpaket wird ja auch die Kanalinformation sehr grob als Boolesche Daten übertragen.
Ich habe mich schon oft gefragt, was man damit anstellen könnte.
Vielleicht wäre ja die Umschaltung zwischen Betrieb mit und ohne FrSky IDs eine sinnvolle Anwendung.
Man müsste halt dann immer einen Kanal mit entsprechendem Festwert mit übertragen.
Das kann z.B. der Kanal 16 sein, am Empfängerausgang muss dieser ja nicht vorhanden sein.
Man könnte dann je nach Modell mal die eine oder die andere Betriebsart verwenden.
Idealerweise wird das so implementiret, dass bei fehlendem Steuerkanal defaultmäßig der Betrieb ohne FrSky IDs ausgewählt ist.
Da muss ich dann mal schauen, was im M-Link Paket für nicht übertragene Kanäle als Kanalinfo auftaucht.

Ich hätte dann wieder eine Version, was ein riesiger Vorteil wäre.
Mal schauen, ob/wann ich Zeit dazu finde, das anzugehen, und ob dabei irgendwelche Knackpunkte auftauchen.

Watch this space...

P.S.: Meine X10S ist jetzt erst mal zum Testsender für das FrSky OS degradiert worden.
Diese Software ist gar nicht sooo schlecht, wenn auch weitgehend von Futaba abgekupfert.
Mit einigen OpenTX Features versehen, bietet sie eigentlich sehr viel, sicherlich wären meine Modelle damit alle problemlos zu programmieren.
Was halt nicht geht, ist das Einspeisen von externen Telemetriedaten, wodurch der Einsatz des M-Link Konverters ausscheidet.

Konverter Bug bei Watchdog Timer Reset

Konverter Bug bei Watchdog Timer Reset

Hallo zusammen,

jetzt hatte ich doch Gelegenheit, am Konverter was zu verbessern, nämlich einen Bug mit dem Watchdog Timer zu beseitigen.
Es handelt sich eigentlich um einen schwerwiegenden Fehler, der aber in der Praxis weitgehend bedeutungslos sein dürfte.
Außerdem tritt der Fehler nicht auf, wenn der Optiboot Bootloader auf dem Mikrocontroller drauf ist.
Dieser händelt offensichtlich den Watchdog so, dass nichts passiert.
Ich habe den Fehler gefunden, als ich nach langer Zeit wieder mal mit ISP Programmer ohne Bootloader geladen habe.

Das Problem besteht darin, dass sich der Konverter beim Auslösen eines Watchdog Timer Resets wegen fehlender M-Link Daten aufhängt.
Da das in der Praxis in der Regel dann passiert, wenn man nach einem Flug den Sender ausschaltet, spielt es normalerweise keine Rolle.
Nur wenn man zwischen M-Link und FrSky Modellspeichern hin- und herwechselt, ohne den Sender auszuschalten, kann das relevant sein.
Und auch nur bei der X9D und X9E, da hier der Konverter an der separaten Buchse hängt, wo er dauernd eingeschaltet ist.

Eine kurze Recherche im Internet hat ergeben, dass der Watchdog Timer der AVR µCs nach einem Watchdog Reset aktiviert bleibt.
Darüber hinaus wird der Timeout auf den kleinsten Wert (15 ms) gesetzt.
Wenn der Watchdog von der Software jetzt nicht innerhalb dieser Zeit zurückgesetzt wird, kommt es zu einer endlosen Folge von Watchdog Resets.

Wenn man das weiß, ist die Lösung des Problems sehr einfach.
Man muss nur ganz am Anfang des Programm erst mal den Watchdog Timer deaktivieren, um diesen Fall abzufangen.
Ich habe das bereits gemacht und stelle die beiden HEX Files für die beiden Konverter Versionen hier ein.
Außerdem hänge ich noch das geänderte Source File mit dran (ist das gleiche für beide Versionen).

Wie gesagt, wer mit Optiboot unterwegs ist, hat ohnehin kein Problem (zu anderen Bootladern kann ich nichts sagen).
Und wer nach einem Flug seinen Sender erst mal ausschaltet, hat auch keins.
Aber es ist ein Fehler, keine Frage.

Horus X10S mit HFMG2 geht doch!

Horus X10S mit HFMG2 geht doch!

Mahlzeit,

ich dachte ich berichte mal kurz über die neueste Entwicklung in Sachen X10S und M-Link.
Da das FrOS nicht annähernd an OpenTx herankommt, hat mir die Sache natürlich keine Ruhe gelassen.
Schließlich ist OpenTx der (einzige) Grund, warum ich FrSky Sender habe.

Also habe ich vor ein paar Tagen mal ausführlich mit dem HFMG2 Modul und dem Sender herumprobiert.
Und tatsächlich habe ich eine Einbaulage gefunden, die eigentlich sogar besser ist als die ursprüngliche Lösung.
Es wird keine zusätzliche Halterung mehr benötigt.

Der Trick besteht im wesentlichen darin, das Modul andersrum einzubauen, da das höchste Bauteil der Summer ist, der dann nach unten zeigt.
Dadurch kann man das Modul etwas höher setzen, und es gibt keine Kollision mehr mit dem Knüppelaggregat.
Ich habe das schon so eingebaut, jetzt muss nur noch der Konverter neu verdrahtet werden.

Wenn alles fertig ist, gibt es natürlich auch Fotos.
Dann warte ich nur noch auf OpenTx 2.2.2, damit wird dann auch das permanente Rauschen weg sein.
Dann kann die X10S doch noch die Nachfolge meiner X9E antreten.

Bis dann.

Tach zusammen,

@Reinhardt: toll, dass Du an dem Thema dran bleibst.
Bin gespannt, wann Du die aktuellsten Bilder veröffentlichst. Die X10S hat meine X9D mehr oder minder bei allen Aktivitäten "ersetzt". An Deinem Thema bin ich weiter interessiert.

Danke für Deine Infos.

Gruß
Frank

Hallo zusammen,

heute habe ich endlich Fotos vom geänderten Einbau des Moduls gemacht.
Man sieht, dass im Vergleich zum vorherigen Einbau das Modul andersrum und mehr in Richtung Akku eingebaut ist.





Der Konverter-Einbau im Modulschacht steht noch aus, aber ich kann schon mal mit M-Link fliegen.

Hallo zusammen,

da es hier ruhig geworden ist, gehe ich mal davon aus, dass die Konverter alle klaglos ihren Dienst verrichten.
Meiner tut es jedenfalls, und damit muss irgendwann ein neues C-Projekt her, damit ich nicht alles verlerne.

Ich bin daher derzeit bei den Vorüberlegungen zu einem "umgekehrten" Konverter, mit dem sich (im Modell) S-Port Sensoren an den MSB anbinden lassen.
Meine bisherigen Recherchen haben ergeben, dass das für die gängigen FrSky Sensoren problemlos machbar sein dürfte.
Ich habe diverse Sensoren von FrSky hier rumliegen, es würde mir also auch einen handfesten Vorteil bringen, wenn ich diese an einem M-Link Empfänger betreiben könnte.
Denn ich muss gestehen, dass ich mir (nachdem ich einen meiner vier FrSky Sender verkauft habe) zur Abwechslung mal wieder einen Multiplex Sender, nämlich eine Cockpit SX12 gegönnt habe.
Ich bin von dem Teil recht angetan, die Bedienung über das Touch-Display ist wirklich gelungen, und mit der neuesten Software ist sie schon fast ein würdiger Nachfolger der Royal.
(In manchen Belangen ist sie dieser bereits überlegen.)
Mit einem edlen Carbon-Pult ist das ganze auch schön leicht (zum Hangfliegen z.B.), so dass ich schon fast alle (E-)Segler darin programmiert habe.

Man könnte später sogar über eine Weiterentwicklung des bestehenden Telemetrie-Konverters nachdenken.
Dieser würde dann statt des (veralteten) D-Protokolls das S-Port Protokoll zum einspeisen in den Sender benutzen.
Aber das ist jetzt noch Zukunftsmusik.

Sollte ich mich endgültig zur Realisierung des S-Port/MSB Konverters entscheiden, werde ich ggf. dafür einen eigenen Thread aufmachen (wahrscheinlich in der Rubrik Mikrocontroller).
Aber wenn ich ehrlich sein soll, habe ich bereits das Atmel-Studio angeworfen und angefangen, das Projekt aufzusetzen.
Ich kann einiges von meinen früheren Projekten zur MSB Sensorik einfach weiterverwenden, z.B. das gesamte Handling der MSB Masterabfragen vom M-Link Empfänger.
Letzlich wird das auch eine Art "Sensor", bei dem halt die Daten von einem anderen Bus kommen.

Aber das soll jetzt erst mal genügen, schaun mer mal...

Ach ja, noch ganz wichtig: Ich werde OpenTX nicht untreu werden, drei FrSky Sender habe ich ja schließlich noch.

Hallo Reinhardt,
schön von dir und deinen Plänen zu hören!
Ein universeller Adapter für Fremd-Sensoren klingt sehr spannend! Da wird es sicher deutlich mehr Interessenten geben als beim Konverter.
Gratulation zur MPX Cockpit. MPX dürfte mit dem letzten Update die letzten "Beanstandungen" behoben haben und somit eine ordentliche Option zur PTX haben.
Zum Konverter... Ja,, auch ich bin fremd gegangen... Leider hatte ich heuer kaum Zeit zu Fliegen. Wenn, dann wars doch immer die MPX PTX.
Eine Option, mehrere Sender auf einen Empfänger zu binden, das wäre mal was! Wären alle Sender gleichzeitig auf Empfänger gebunden, würde ich sicher öfter Frsky nehmen.
Ich freue mich schon, mehr von dienen neuen Projekten zu lesen und werde sicher fleißig testen, falls dies gewünscht sein würde!
lg
Roland

Donaufisch66 schrieb:

Ein universeller Adapter für Fremd-Sensoren klingt sehr spannend! Da wird es sicher deutlich mehr Interessenten geben als beim Konverter.

Zum Vergrößern anklicken....

Hallo Roland,

schön, wieder von Dir zu hören, mal schauen, wann sich Kalle zu Wort meldet.
Äähm, aber von einem universellen Konverter war nicht die Rede, ich möchte lediglich meine S-Port Sensoren an den MSB der M-Link Empfänger anschließen können.
Somit wird sich der Interessentenkreis vermutlich ziemlich genau auf diejenigen beschränken, die sich auch für den M-Link/OpenTX Konverter interessiert haben.
Abzüglich derjenigen, die ausschließlich M-Link einsetzten, da diese vermutlich keine S-Port Sensoren haben werden.
Aber warten wir es mal ab.

Ich will das nicht zuletzt auch deswegen machen, um das S-Port Protokoll kennenzulernen.
Wie gesagt, könnte man dann später mal den Konverter modernisieren.
Wer weiß, wie lange die OpenTX Jungs das alte D-Format noch mitschleppen werden.
Naja, was ich bisher so rausgefunden habe, scheint der S-Port kein Hexenwerk zu sein.
Und er ist 6-mal so schnell wie das D-Protokoll, das ist sicher kein Nachteil.

In diesem Sinne.

Hallo Reinhardt,
Ja, du hattest nicht von einem universellen Konverter gesprochen.
Ich glaube aber, sobald du das Projekt online stellst, werden erste Anfragen kommen, ob andere Systeme auch implementierbar wären..
Für uns nicht relevant. Auch ich habe ein paar frsky Sensoren, die gerne über mlink senden würden ;-)
Alleine der Preisunterschied zwischen frsky und mlink könnte viele bewegen dein Projekt zu verfolgen.
Lg Roland

M-Link Konverter

M-Link Konverter

da es hier ruhig geworden ist, gehe ich mal davon aus, dass die Konverter alle klaglos ihren Dienst verrichten.

Vielen Dank an Reinhardt Werbik und alle welche zum Konverter beigetragen hatten. Bei mir funktioniert er seit einem halben Jahr problemlos. Von RIX erhielt ich ein fertig programmiertes Arduino Modul. Ich flog sehr viel in den Bergen mit meinen Segelfliegern und schätze den leichten und kompakten Sender mit den 9 Telemetrie Werten pro Seite im Display sehr. Ich lasse Distanz, Höhe, Geschwindigkeit, Steigen, etc anzeigen oder ansagen. Auf der gleichen Seite habe ich auch Flugrichtung, Richtung vom Start zum Modell und relative Flugrichtung (180° = genau auf mich zu, 360° = genau von mir weg). Da habe ich im Notfall ohne umzuschalten alle Werte auf einer Seite um das Modell am Himmel zu lokalisieren, falls es aus dem Sichtbereich gerät. Ich bin sehr zufrieden mit der Kombination aus ehemaligem JR/Graupner Gehäuse, openTX und M-Link Signalübertragung.
Ein Detail gilt es noch zu lösen: Ich kann mit MPX Empfänger und SM Varios (unisens, GPS Logger2, unilog) kein Vario Ton generieren. Im Display habe ich die Vario Anzeige mit Zahlen. Daher kann ich nicht verstehen, dass ich keinen Ton erhalte. Der Ton sollte doch nur das Umsetzen des Vario Wertes sein. Mit Frsky Empfänger und Frsky Vario oder den oben genannten SM Vario mit Frsky Empfänger funktioniert die Tonausgabe einwandfrei. Hat hier jemand eine Lösung? Bis jetzt nutze ich noch den Souffleur für den Varioton.

Zu meinem Umbau:
Ich verwendete ein MPX HFMG2 Modul (Platine) und baute es in den Modulschacht der X9D plus ein. Darüber das Arduino für die Umsetzung der Telemetrie Daten auf das Senderdisplay. Die Stromversorgung nahm ich, anders als vorgeschlagen, vom Plus im Modulschacht. Das hat den Vorteil, dass die Arduino Platine nur mit Strom versorgt wird, wenn das MPX HF Modul in Betrieb ist und beim Gebrauch des Frsky Moduls es stromlos bleibt. Die zweite Antenne montierte ich gleich unter der Frsky Antenne.

Dass das vario nicht normal funktioniert ist höchst ungewöhnlich. Wie ist denn die Aktualisierungsrate des Wertes? könnte es damit zu tun haben?

Wie gesagt, die Anzeige im Display zeigt sehr realistische Werte. Diese werden auch schnell aktualisiert. Beim SM-Vario kann man die Trägheit in drei Stufen einstellen. Nur der Ton fehlt. Am Arduino veränderte ich nichts (und habe auch keine Möglichkeit dazu). Ich erhielt es via rix von Reinhardt(?). Gleiches Vario mit Frsky Empfänger funktioniert einwandfrei.

und du hast wie üblich im telemetry menü die varioquelle vspd eingestellt ? entschuldige die dämliche frage

Hallo zusammen,

hier tut sich ja plötzlich wieder was.

Ich sehe auf den ersten Blick zwei mögliche Gründe für den fehlenden Varioton.

1. Die Varioquelle ist nicht auf den richtigen Sensorwert eingestellt, wie schon von Simon angeregt.

2. OpenTx erwartet für den Varioton einen Sensorwert mit der vordefinierten ID 0x30 für das Vario gemäß D-Protokoll.

Fall 1 lässt sich leicht überprüfen.

Zu Fall 2:
Es gibt vom Konverter zwei Versionen, von denen die eine ganz auf die vordefinierten FrSky IDs verzichtet, was universeller ist.
Falls 2. zutrifft, funktioniert der Varioton mit dieser Version nicht, da die ID in diesem Fall von der MSB Adresse bestimmt wird.
(ID 0x30 kann in diesem Fall nicht vorkommen.)
Die zweite Version benutzt für einige wenige Parameter (auch für das Vario) die vordefinierten FrSky IDs.
Mit dieser Version müsste der Varioton in jedem Fall funktionieren.

Welche Version des Konverters ist den drauf?