OpenTX - Multiplex MLINK Konverter

[Reinhardt Werbik]

Hallo zusammen,

mal ein kurzes Update zum Konverter.

Ich habe in der vergangenen Woche die Software ein wenig umgestellt,
um eine bessere Modularität für zukünftige Erweiterungen/Änderungen zu haben.
Und zwar habe ich im wesentlichen das mittlerweile recht umfangreiche Daten-Konvertierungsmodul
in drei kleinere Module mit zugehörigen Header Files aufgeteilt.
Das macht die weiter oben angesprochenen Änderungen zur Minimierung der Latenz einfacher.

In diesem Zusammenhang bin ich zu dem Schluss gekommen, dass es besser ist, die Baro- und GPS-Höhe
nicht mehr mit den vordefinierten FrSky IDs zu übertragen, sondern als zusätzliche Parameter mit ID gemäß MSB Adresse.

Das hat (neben deutlichen Erleichterung bei den Änderungen zur Latenz-Verbesserung) folgende Vorteile:

Man muss nicht mehr feste MSB Adressen (6 bzw. 10) für diese beiden Parameter verwenden.

Das umständliche, FrSky eigene Verfahren mit separat übertragenen Nachkommastellen (und 2 IDs pro Parameter) entfällt.
Es waren die einzigen Parameter, bei denen das noch notwendig war.

Es gibt mittlerweile eine ganze Reihe anderer MSB Parametern mit der Werteklasse 8, z.B. 2-D und 3-D Entfernungen vom GPS.
Diese konnten bisher nicht auf den Adressen 6 und 10 übertragen werden, da sie dort als Baro- bzw. GPS-Höhe interpretiert worden wären.

Der einzige "Nachteil" dieser Änderung besteht darin, dass man für die beiden Höhen jetzt einen Namen und die Einheit selbst vergeben muss.
Das ist glaube ich zu verschmerzen, im Hinblick auf die jetzt größere Flexibilität.

Ich werde weiter berichten.

 

[Donaufisch66]

Hallo Reinhardt,
Das klingt super.
Ich hätte eine Frage zur Priorisierung von Adressen. Setzte ich für das Vario eine Priorität im Empfänger, kommt dieser Vorteil auch durch den Konverter ?
Ich habe mich noch nicht mit dem Thema beschäftigt, hatte aber unlängst einen Empfänger upgedatet und Vario auf "prio" gesetzt.
Parktisch wird man kaum was merken, aber wie schaut es theoretisch aus ?
Kommt der Konverter damit klar?
LG Roland

 

[Reinhardt Werbik]

Hallo Reinhardt,
Das klingt super.
Ich hätte eine Frage zur Priorisierung von Adressen. Setzte ich für das Vario eine Priorität im Empfänger, kommt dieser Vorteil auch durch den Konverter ?
Ich habe mich noch nicht mit dem Thema beschäftigt, hatte aber unlängst einen Empfänger upgedatet und Vario auf "prio" gesetzt.
Parktisch wird man kaum was merken, aber wie schaut es theoretisch aus ?
Kommt der Konverter damit klar?
LG Roland

Hallo Roland,

im Moment ist es so, dass die Parameter nach einer fest vorgegebenen Sequenz zum Sender geschickt werden.
Das ist unabhängig davon, wie oft und wann die Werte vom M-Link Modul aktualisiert werden.
Ein Problem hat der Konverter damit nicht, er nutzt allerdings den Vorteil einer priorisierten Übertragung eines einzelnen Parameters nicht aus.
Wobei die Frage ist, was die Priorisierung beim Einsatz eines externen M-Link Moduls wirklich bringt.
Man darf nicht vergessen, dass es nur alle 100 ms zwei Telemetriewerte ausgibt (bei Fast Response alle 70 ms).
Der Vorteil kommt wohl in erster Linie bei der ProfiTX zum Tragen, die nicht an das Ausgabeprotokoll der Module gebunden ist,
sondern alles schön intern abarbeiten kann.

Wie schon gesagt, werde ich den Konverter so ändern, dass er mit Priorität die zuletzt aktualisierten Parameter zum Sender schickt.
Dann wird zumindest eine zusätzliche Latenz vermieden bzw. minimiert.

Wahrscheinlich werde ich im Zuge der geplanten Änderunge auch die festen Adressen für Empfängerspannung und LQI rausnehmen.
Da diese Parameter jeweils eine eigenen Werteklasse haben, die nicht mit anderen Parametern besetzt sein kann, dürfte das kein Problem sein.
Es wird halt dann immer die niedrigste Adresse mit der passenden Werteklasse genommen.
Bei bestehenden Konfigurationen mit den Standard-Adressen 0 bzw. 1 merkt man das dann gar nicht.

Für die oben angesprochenen Änderungen bzgl Baro- und GPS-Höhe muss man einmalig im Sender die ID anpassen.
Eine neue Sensorsuche dürfte nicht erforderlich sein, dass werde ich aber explizit testen, wenn es soweit ist.

Watch this space.

 

[Reinhardt Werbik]

Wahrscheinlich werde ich im Zuge der geplanten Änderunge auch die festen Adressen für Empfängerspannung und LQI rausnehmen.
Da diese Parameter jeweils eine eigenen Werteklasse haben, die nicht mit anderen Parametern besetzt sein kann, dürfte das kein Problem sein.
Es wird halt dann immer die niedrigste Adresse mit der passenden Werteklasse genommen.
Bei bestehenden Konfigurationen mit den Standard-Adressen 0 bzw. 1 merkt man das dann gar nicht.

Ääähm, das war teilweise natürlich Blödsinn.
Die Empfängerspannung hat selbstredend keine eigen Werteklasse, sondern nutzt die Klasse 1, wie jede andere Spannung auch.
Ich muss also obige Aussage revidieren, oder wie man auf neudeutsch sagen würde: I reserve my position ...

 

[kalle123]

... oder wie man auf neudeutsch sagen würde: I reserve my position ...

Reinhardt, du Quelle voll Weisheit, oder sind das noch die Nachwirkungen der "guten Seeluft"?

Aber, wenn du was Neues "auf den Markt schmeißt". Ich bin da erst im Herbst/Winter dabei. Dann werde ich mir auch mal openTX 2.2.x näher anschauen.

Hab gerade fast einen Monat damit verplempert, von PCLinuxOS KDE4 (die Jungs wollen unbedingt auf KDE 5 - igitt!) auf Debian Stretch Xfce umzusteigen. Dann festgestellt, das es damit Probleme mit DVB-S auf dem Desktop gab, die kurz-/mittelfristig nicht abzustellen waren. Die Debian Jungs pflegen das "wahre" Linux, da spielt Multimedia Klimbim keine Rolle. Jetzt bin ich seit 3 Tagen auf Linux Mint 18.2 Xfce. Et löppt ....

Das nur am Rande, ich bleib am Ball.

Grüße KH

 

[Reinhardt Werbik]

Reinhardt, du Quelle voll Weisheit, oder sind das noch die Nachwirkungen der "guten Seeluft"?

Aber, wenn du was Neues "auf den Markt schmeißt". Ich bin da erst im Herbst/Winter dabei. Dann werde ich mir auch mal openTX 2.2.x näher anschauen.

Hab gerade fast einen Monat damit verplempert, von PCLinuxOS KDE4 (die Jungs wollen unbedingt auf KDE 5 - igitt!) auf Debian Stretch Xfce umzusteigen. Dann festgestellt, das es damit Probleme mit DVB-S auf dem Desktop gab, die kurz-/mittelfristig nicht abzustellen waren. Die Debian Jungs pflegen das "wahre" Linux, da spielt Multimedia Klimbim keine Rolle. Jetzt bin ich seit 3 Tagen auf Linux Mint 18.2 Xfce. Et löppt ....

Das nur am Rande, ich bleib am Ball.

Grüße KH

Mach Dir male keinen Kopp, noch habe ich nichts anzubieten.
Das Ersetzen des aktuellen primitiven Verfahrens, alle Parameter immer in gleicher Reihenfolge rauszuschicken, ist nicht ganz ohne.
Vor allem birgt es viele Fehlermöglichkeiten.
Ich werde mir also Zeit lassen, bevor ich was Neues hier ins Rennen werfe.
Schließlich funktioniert der Konverter und bevor ich es nicht ausgiebig getestet habe, gibt es nichts.

A propos Seeluft, die werde ich hoffentlich in nicht allzu ferner Zukunft öfter schnuppern.
Ich habe Maßnahmen ergriffen, um mein Arbeitsleben vorzeitig zu beenden (in 3 1/2 Jahren, um genau zu sein).
Und dann ist fest geplant, einmal imn Jahr einige Wochen an Nord- oder Ostsee zu verbringen.

 

[gruni]

Reinhardt, du Quelle voll Weisheit, oder sind das noch die Nachwirkungen der "guten Seeluft"?

Aber, wenn du was Neues "auf den Markt schmeißt". Ich bin da erst im Herbst/Winter dabei. Dann werde ich mir auch mal openTX 2.2.x näher anschauen.

Hab gerade fast einen Monat damit verplempert, von PCLinuxOS KDE4 (die Jungs wollen unbedingt auf KDE 5 - igitt!) auf Debian Stretch Xfce umzusteigen. Dann festgestellt, das es damit Probleme mit DVB-S auf dem Desktop gab, die kurz-/mittelfristig nicht abzustellen waren. Die Debian Jungs pflegen das "wahre" Linux, da spielt Multimedia Klimbim keine Rolle. Jetzt bin ich seit 3 Tagen auf Linux Mint 18.2 Xfce. Et löppt ....

Das nur am Rande, ich bleib am Ball.

Grüße KH

Hallo Kalle,

kurze Einmischung off topic:
Ich musste feststellen, daß OTX2.2 unter Mint nur in der 64Bit Version läuft. Mint läuft auf einer 32gb SSD aus einem alten WeTab in einem Lenovo T400, das läuft dann neben WXP im Dualboot und ist sehr angenehm zu bedienen und vor allem sehr schnell. Aus dem standby ohne Anmeldebildschirm unter 2...3sek. Fast wie Ipad ;->
OTX2.2 war eigentlich der Grund, mich mit Mint/Linux zu beschäftigen. Ich hatte 3Wochen Urlaub, in der Zeit habe ich nur 2mal Windows wegen dem Logicanalyzer gestartet...
OTX2.2 hab ich dann unter Mint auf die Taranis gebracht. Auch das läuft.
Was nicht mehr läuft: Ich hatte vorher das 32bit Mint drauf, da konnte ich Salea unter WINE starten, wenn manns mal kapiert hat, unter Mint 64bit startet Wine die XP-Programme nicht mehr...
Haste da nen Tip?

off topic off

beste Grüsse, Gruni

 

[kalle123]

OFF TOPIC! Hallo Gruni

Hier Saleae auf Mint 18.2 Xfce 64bit. Null problemo.

Lade dir die Linux Version bei Saleae. Entpacken. Im Unterverzeichnis "Drivers" findet sich ein bash script, das die beigefügte "99-SaleaeLogic.rules" nach /etc/udev/rules.d/ kopiert. Brauchst du, um Saleae als normaler user ausführen zu können. Das ist eigentlich alles .... (Ach, und du musst als user natürlich in den entsprechenden Gruppen sein (dialout, tty, plugdev, uucp hab ich mal dazugenommen ...))

@ Reinhardt.

"A propos Seeluft" Schau, das du raus kommst aus dem Job. Jedes Jahr in Gesundheit ist ein gewonnenes Jahr. Habs gemacht und nicht bereut!

Zur See, Reinhardt, das Bild hier

Ist sehr lange her. so um 1980 rum. Fahrt Karibik -> Europa im Atlantik. M/V Pocahontas (Kühlschiff mit 200.000 boxes Chiquitas an Bord)
Ich esse auch heute noch immer gerne Bananen!!! Ach, den Dampfer gibt es nicht mehr. Ist irgendwo in Pakistan, Indien oder Bangladesch unter den Brenner gekommen. Waren wirklich schöne Schiffe ....

Grüße KH

 

[gruni]

Hallo Kalle,

danke für den Tip, ich bin noch Linux dummie. Wenn ich wieder im Lande bin, probiere ich es aus. Hab hier "nur" das Siemens FieldPG... da darf ich nicht mit experimentieren...

Grüsse, Gruni

 

[kalle123]

Ach, noch was, Gruni.

(Auch wieder OFF TOPIC!)

Mach dir wg. 32 und 64 bit support keine Gedanken.

https://wiki.debian.org/Multiarch/HOWTO

Die Buntus und Mint gehören ja alle zur Debian Familie. War lange mit Wheezy, Jessie und kurz mit Stretch unterwegs.

Musste gestern noch meinen Brother Drucker, Scanner unter Mint in die Gänge bringen.

Für den Drucker wurden dann ne Masse 386 er libs installiert. MULTIARCH halt ....
-------------------------------------------------------------------------------------------------------------------------
Ich bleib erstmal bei openTX 2.1.8. Mach momentan ALLES, WAS ES SOLL

Mach dran - Grüße KH

 

[Reinhardt Werbik]

Hallo zusammen,

hier ist jetzt der letzte Stand meiner Überlegungen bzgl. fest zugeordneter MSB Adressen.

Die Adressen 0 und 2 bleiben wie bisher den Spannungen A1 und A2 zugeordnet.
Wenn A1 oder A2 nicht benötigt wird, kann auf der zugeordneten Adresse ein beliebiger anderer Parameter übertragen werden.

Die feste Zuordnung der Adresse 1 zum RSSI (LQI) habe ich rausgenommen, da unnötig.
Als RSSI wird der LQI Wert mit der niedrigsten MSB Adresse ausgegeben.
Meistens wird man allerdings die standardmäßig eingestellte Adresse 1 lassen.

Ich werde weiterhin eine Höhe als Parameter mit FrSky ID ausgeben.
Diese muss auf Adresse 6 liegen und erscheint dann als "Alt".
Jeder Parameter auf Adresse 6 mit Werteklasse 8 wird als "Alt" ausgegeben (das kann auch eine Höhe vom GPS sein).
Wird eine Höhe auf einer anderen Adresse übertragen, erscheint sie als zusätzlicher Parameter mit ID gemäß Adresse.
Durch diese Zuordnung können die beiden Parameter vom MPX Vario mit den entsprechenden Namen ausgegeben werden.
(Vorausgesetzt die Höhe liegt auf Adresse 6.)
Es wäre etwas komisch gewesen, wenn bei diesem Standardsensor ein Wert mit vordefinierter ID (die Steigrate) und ein Wert mit ID gemäß Adresse aufgetaucht wäre.

Jetzt muss ich das alles nur noch so implementieren.

 

[Reinhardt Werbik]

Hallo zusammen,

die Umstrukturierung des Codes in mehr Teilmodule ist jetzt abgeschlossen.
Die geänderte feste Adresszuordnung ist ebenfalls bereits implementiert.
(Adressen 0, 2 und 6, s. oben)

Das Programm ist kompiliert, auf mein Testboard geladen und läuft soweit.
Damit habe ich jetzt eine Referenzkonfiguration, bevor ich die Änderungen zur Latenzminimierung angehe.
Denn dabei gibt es jede Menge Möglichkeiten, Fehler einzubauen.

Damit ich auch übermorgen noch durchblicke, habe ich die jetzige Architektur des Konverters
mit den wesentlichen Schnittstellen mal in einem Blockdiagramm dargestellt.
Das will ich Euch natürlich nicht vorenthalten.



Neuen Code gibt es noch nicht, da sich funktional ja bis jetzt praktisch nichts geändert hat.

 

[elral]

Hallo zusammen,

nachdem ich in den letzten Wochen doch wieder mehr zum fliegen komme, habe ich mich etwas über die Programmierung meines "neuen" Senders geärgert.
Nun habe ich mich durchgerungen, eine X9E zu kaufen. Ich muss die mal in der Hand haben und schauen wir die Haptik ist.
Wenn ich die behalten sollte, ist mein Plan ein M-Link Modul einzubauen (ich habe noch zwei HFMG2) und für die Telemetrie den Konverter zu nutzen.

@Reinhard,
hast Du von Deinem Einbau bereits Bilder veröffentlicht? Ich habe zwar einige Threads mittlerweile gelesen, diesbezüglich aber "nur" ein Bild vom Konverter gefunden.
Gibt es etwas besonderes zu beachten?
Antwort gerne auch per PN.

Und sorry wenn es nicht ganz zu diesem Thema passt.

Grüße

Ralf

 

[Reinhardt Werbik]

Hallo Ralf,

Hier hatte ich mal zwei Bilder von meinem Einbau gepostet.
Ich verwende allerdings ein HFMG1.
Das HFMG2 musst Du halt irgenwie an den Modulbügeln festmachen und dann ein Kabel von den Pins des Modulschachts zum Modul machen.
Vielleicht kannst Du Dir beim HFMG2 die Antennenverlängerung sparen, wenn Du es so einbaust, dass die Antenne nach vorne abgeht.

Für den LED-Taster habe ich ein zusätzliches Loch neben dem bereits vorhandenen für die Antenne gebohrt.

Du könntest auch eine externe Status LED in ein freies Schalterloch einbauen (mit Vorwiderstand!).
Der Konverter gibt das Steuersignal für die LED des Arduino Boards parallel an einem Ausgangs-Pin aus.

Theoretisch könntest Du den Konverter auch gleich an den Modulschacht-Pins anschließen.
Dann müsstest Du in der Telemetrie nicht mehr die Option "FrSky Cable" auswählen, sondern einfach das D-Protokoll.
Der Vorteil wäre, dass der Konverter nur läuft, wenn auch das M-Link Modul aktiv ist.

Der Einbau ist in jedem Fall keine große Sache.
Das Ergebnis ist ein perfekter M-Link Sender, mit dem man auch FrSky Empfänger betreiben kann.

 

[elral]

Hallo Reinhardt,

danke für die Infos. Ich habe es mal unter Companion durchgespielt.
Serielle Schnittstelle ausschalten, dann unter Telemtrie FrSky D anwählen.

Nur an welchem Pin wird dann das Signal eingespeist? Laut Helles Anleitung gibt es dort:
- SPORT Output: S-Port-Signal für Update am S-Port, XJT, Empfänger, Sensoren
- GND Signal-Masse
- VMAIN Akkuspannung ungeregelt 9V - 11V
- Heart_Beat Input: weitere Möglichkeiten für Inputs S-Bus, CPPM (Lehrer S-Bus)
- CPPM Output: für passende HF-Module CPPM, PXX, DSM2
Demnach ist "nur" Heart_Beat ein Input, also dort?
Und wie meinst Du das, dass der Konverter nur aktiv ist, wenn auch das M-Link Modul aktiv ist?

Vielen Dank und Grüße

Ralf

 

[Reinhardt Werbik]

Hallo Ralf,

der richtige Pin im Modulschacht ist der SPort Pin.
Dieser hat verschiedene Funktionen, er dient nicht nur zum Updaten externer Geräte.

Du musst in den Sendergrundeinstellungen die serielle Schnittstelle auf "Telemetrie" einstellen.
Im Modell unter Telemetrie dann als Protokoll "FrSky D" auswählen.
Mit diesen Einstellungen kannst Du die Telemetriedaten über den SPort-Pin im Modulschacht einspeisen.
Mit der Telemetrie-Option "FrSky D Kabel" werden die Telemetriedaten vom separaten Anschluss auf der Hauptplatine gelesen.
Dieser ist aber bei der X9E im Lieferzustand nicht mit einer Stiftleiste bestückt.
Ich habe diesen Anschluss bestückt und den Konverter dort angeschlossen, dann ist er immer an.
Deswegen habe ich einen Watchdog Reset implementiert, der den Konverter resettet, wenn nichts mehr vom Modul ankommt, weil dieses aus ist.

Das ist etwas verwirrend, da sich der Begriff serielle Schnittstelle nicht explizit auf den separaten (nicht bestückten) Anschluss bezieht.
Dieser wird nur mit der Telemetrie-Option "FrSky D Kabel" herangezogen.

Die Versorgungsspannung im Modulschacht wird nur eingeschaltet, wenn das externe M-Link Modul benutzt wird.
Somit ist auch nur dann der Konverter an, falls er dort angeschlosen wird.

 

[Reinhardt Werbik]

Siehe auch hier.

 

[elral]

Hallo Reinhardt,

vielen Dank! Jetzt kenne ich auch den Unterschied zwischen "FrSky D" und "FrSKY D (Kabel)".

Die X9E habe ich eben abgeholt und ausgepackt. Während sie lädt gehe ich noch eine Runde fliegen.
Zum Wochenende werde ich mich dann entscheiden, ob sie meinen bisherigen Sender ersetzen wird.

Grüße

Ralf

 

[Donaufisch66]

Hallo Ralf,
Auf der Platine findest du einen Lötport "p12". An diesem musst du einen Stecker löten und das Mlink Signal einspeisen.
LG Rolandp

 

[Onkel Ernst]

Grundlagenproblem

Grundlagenproblem

Hallo zusammen,
Konnte mir kürzlich noch ein neues HFMG3 beschaffen und möchte nun den Konverter bauen. Da für mich solche Microcontroller neu sind, habe ich ein Grundlagenproblem. Wie kriege ich das Hex-File geflasht? Ich habe den Arduino-1.8.4 installiert und ich kann auch "bink" flashen. Will ich aber das Hex-File öffnen kommt die Meldung, dass nur *.ino und *.pde möglich ist. Hat mir jemand einen tip?
Gruss Ernst